[RESOLVED] Bug Report: Incorrect line end in HTTP headers

Danal

RFC 2616, Section 2.2 "Basic Rules" states:

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.

CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>

Note: This is not related to platform differences in "line end" in any way. The RFC is extremely explicit in specifying the line end for HTTP 1.1 protocol specifically to avoid these issues.

.

I recently discovered, while modifying an existing HTTP parser to work with Duet RepRap, that the line ends are not RFC compliant. Duet RepRap inserts "LF", 0x0A, only, at each protocol element boundary.

I will work around this for the moment; nonetheless, it really should be corrected.

Here is an example of a header pulled from a '/rr_status?type=1' request on a printer running a very recent version:

Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later
Firmware Version:	2.02RC3(RTOS) (2018-10-17b2)
WiFi Server Version:	1.21
Web Interface Version:	1.22.4-b1

00000000:  4854 5450 2f31 2e31 2032 3030 204f 4b0a 4361 6368 652d 436f  :HTTP/1.1 200 OK.Cache-Co
00000018:  6e74 726f 6c3a 206e 6f2d 6361 6368 652c 206e 6f2d 7374 6f72  :ntrol: no-cache, no-stor
00000030:  652c 206d 7573 742d 7265 7661 6c69 6461 7465 0a50 7261 676d  :e, must-revalidate.Pragm
00000048:  613a 206e 6f2d 6361 6368 650a 4578 7069 7265 733a 2030 0a41  :a: no-cache.Expires: 0.A
00000060:  6363 6573 732d 436f 6e74 726f 6c2d 416c 6c6f 772d 4f72 6967  :ccess-Control-Allow-Orig
00000078:  696e 3a20 2a0a 436f 6e74 656e 742d 5479 7065 3a20 6170 706c  :in: *.Content-Type: appl
00000090:  6963 6174 696f 6e2f 6a73 6f6e 0a43 6f6e 7465 6e74 2d4c 656e  :ication/json.Content-Len
000000a8:  6774 683a 2031 3231 320a 436f 6e6e 6563 7469 6f6e 3a20 636c  :gth: 1212.Connection: cl
000000c0:  6f73 650a 0a                                                 :ose..

Note that each element ends with LF, and the overall headers end with LFLF (which should be CRLFCRLF). It is the overall end that broke the parser...

Thank you for your consideration regarding this bug.

dc42

Thanks for reporting this. I've corrected the source code for release 2.02RC4. Please try that version when I release it.

Danal

Thank you for your quick response! I will try RC4 as soon as it is available.

Danal

This appears to be resolved in 2.02RC5(RTOS) (2018-11-28b1)

(and maybe before, I just now checked it).