[
https://issues.apache.org/jira/browse/MESOS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071427#comment-14071427
]
Tom Arnfeld commented on MESOS-1625:
------------------------------------
Just another update.. RFC 7230 does endorse supporting the blank line in
parsers (http://tools.ietf.org/html/rfc7230#section-3.5) so i'm tempted to just
go ahead and close this issue.
I'm tempted to still suggest removing it, only because this may hinder future
adopters when using new languages or http libraries... any thoughts on this?
For example, I've had to make a patch to
[tornado|https://github.com/tornadoweb/tornado/pull/1124] otherwise it's
impossible to communicate with the mesos API.
> 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)
