[
https://issues.apache.org/jira/browse/MESOS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070105#comment-14070105
]
Tom Arnfeld commented on MESOS-1625:
------------------------------------
After looking a little more I can see Mesos is using chunked encoding, and the
CRLF I linked to is actually correct. I'm still suspicious that libprocess is
sending incorrect CRLF tokens somewhere, and is causing issues with keep-alive
connections.
> 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)
