Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Not A Problem
-
None
-
None
-
None
Description
After a ridiculous amount of time debugging, I think i've found the cause of why i'm unable to connect up a libprocess implementation (in Python, from wickman) to mesos (and the c++ implementation of libprocess).
The bug is caused by libprocess terminating body content with an extra CRLF token as seen here.. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/encoder.hpp#L128
After digging around in the HTTP/1.0 spec i've found the following excerpts that I think back up what I've found... though please correct me if i'm wrong, a little unfamiliar with this.
Full-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).
The above suggests we should write the headers (terminated with \r\n) and then a NULL \r\n line to signify the start of the body, we then write the body.
HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker for all protocol elements except the Entity-Body (see Appendix B for tolerant applications). The end-of-line marker within an Entity-Body is defined by its associated media type, as described in Section 3.6.
The only mention of CRLF in Appendix B is...
The line terminator for HTTP-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.
It wouldn't surprise me if other HTTP frameworks (Go, Java) etc are tolerant of these extra line endings. Though it scares me hugely that removing this line could break literally everything for some users.
Interested to hear your thoughts, benjaminhindman / other libprocess contributors.