[ https://issues.apache.org/jira/browse/MESOS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neil Conway updated MESOS-1625: ------------------------------- Priority: Major (was: Critical) > Extra trailing CRLF being sent after the HTTP body in libprocess > ---------------------------------------------------------------- > > Key: MESOS-1625 > URL: https://issues.apache.org/jira/browse/MESOS-1625 > Project: Mesos > Issue Type: Bug > Components: libprocess > Reporter: Tom Arnfeld > > 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. > {quote} > 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). > {quote} > 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. > {quote} > 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. > {quote} > The only mention of CRLF in Appendix B is... > {quote} > 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. > {quote} > 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. -- This message was sent by Atlassian JIRA (v6.3.15#6346)