mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Arnfeld (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MESOS-1625) Extra trailing CRLF being sent after the HTTP body in libprocess
Date Wed, 23 Jul 2014 07:24:38 GMT

    [ https://issues.apache.org/jira/browse/MESOS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070105#comment-14070105
] 

Tom Arnfeld edited comment on MESOS-1625 at 7/23/14 7:23 AM:
-------------------------------------------------------------

After looking a little more I can see Mesos is using chunked encoding, and the CRLF I linked
to is actually correct, I think. I'm still suspicious that libprocess is sending incorrect
CRLF tokens somewhere, and is causing issues with keep-alive connections.


was (Author: tarnfeld):
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)

Mime
View raw message