Tom Arnfeld created MESOS-1625:
----------------------------------
Summary: 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
Priority: Critical
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.2#6252)
