Re: [Technical Errata Reported] RFC7230 (4667)

> On Apr 13, 2016, at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Digging into the history of this a bit, I see that the implied WSP was made explicit as of draft -16:
>  https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-6.2.1
> ... and subsequently, Julian started to convert it to OWS.
> 
> However, Roy took it out with this commit:
>  https://github.com/httpwg/http11bis/commit/9ff47b1d187bbf2a#diff-48ead163ebcead27fb688b09acb76a43L2282
> 
> There doesn't seem to have been any discussion of that change on the list or the issue that the commit was linked to, and no one seems to have noticed until now.
> 
> Roy, any additional context here?

We discussed it as an editorial issue #36, mostly in Newport Beach and later in Prague, IIRC.
The question was whether the implied whitespace rule from HTTP/1.0 had ever been
intended to apply to chunked encoding (a feature added for HTTP/1.1 in the body of
a message).  It had not.  The next was if there were any examples we knew of where space
was included there.  None.  [ICAP, by the way, is not HTTP.]  That was all discussed
as part of addressing #36.

Later we deprecated extensions in #343, and then we brought them back but with
only the syntax that we know works (no implied whitespace).  Hence, we didn't have the
history or implementations to justify unnecessary whitespace.

Apache httpd's chunk parser doesn't make use of chunk-ext unless it is bypassed
(i.e., a module can implement its own chunk parser).  The core will allow up to
10 bad whitespace between the chunk-size and chunk-ext (to allow for space-padding
of the chunk-size in fixed buffers), and then skip anything other than invalid
control chars between the ";" and the end of line; i.e.,

   chunk-ext      = 0*10<BWS> ";" *( OWS / VCHAR / )

IOW, that parser would support such a fix, but only by accident.  I seriously doubt
we can assume that arbitrary HTTP implementations would expect whitespace in those
places.  It was a stretch to expect that all implementations can handle chunk-ext,
but at least for that we had examples of how they would be implemented.

I don't have a problem with adding whitespace back in there, but I am not at all
confidant that such a choice would be less likely to break things.  I don't want
to play errata ping pong.

....Roy

>> On 14 Apr 2016, at 2:36 AM, Willy Tarreau <w@1wt.eu> wrote:
>> 
>> On Wed, Apr 13, 2016 at 09:05:04AM -0700, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC7230,
>>> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4667
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Alex Rousskov <rousskov@measurement-factory.com>
>>> 
>>> Section: 4.1.1
>>> 
>>> Original Text
>>> -------------
>>> chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
>>> 
>>> 
>>> Corrected Text
>>> --------------
>>> chunk-ext      = *( ";" OWS chunk-ext-name [ "=" chunk-ext-val ] )
>>> 
>>> Notes
>>> -----
>>> The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between ";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace. In my experience, HTTP agents that can parse chunk extensions usually can handle that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507 Section 4.5:
>>> 
>>>     \r\n
>>>     0; ieof\r\n\r\n
>>> 
>>> IMHO, RFC 7230 should either allow OWS before chunk-ext-name or at the very least explicitly document the HTTP/1 syntax change and its effect on parsers used for both ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP intermediaries and ICAP services).
>>> 
>>> I also recommend adding BWS around "=", for consistency and RFC 2616 backward compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and auth-param that have similar syntax.
>>> 
>>> Please also consider adding OWS _before_ ";" for consistency and RFC 2616 backward compatibility reasons. HTTPbis RFCs already do that for transfer-extension, accept-ext,  t-ranking, and other constructs with similar syntax.
>>> 
>>> If all of the above suggestions are applied, the final syntax becomes:
>>> 
>>> chunk-ext      = *( OWS  ";" OWS chunk-ext-name [ BWS  "=" BWS chunk-ext-val ] )
>>> 
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
>>> --------------------------------------
>>> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
>>> Publication Date    : June 2014
>>> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Hypertext Transfer Protocol Bis APP
>>> Area                : Applications
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> 
>> 
>> I think Alex is prefectly right here. I remember we spent less time on
>> chunk extensions by lack of clearly identified users, so it's very likely
>> that some corner cases slipped through the cracks. 
>> 
>> FWIW, haproxy does indeed accept spaces above as Alex suggests them.
>> 
>> Regards,
>> Willy
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
>

Received on Thursday, 14 April 2016 18:21:00 UTC