Re: [Technical Errata Reported] RFC7230 (4667)

[Alex Rousskov <[e-mail]>]

On 04/14/2016 12:20 PM, Roy T. Fielding wrote:

> The next was if there were any examples we knew of where space
> was included there.  None.

> Apache httpd [allows] for space-padding
> of the chunk-size in fixed buffers

Too bad nobody from the Apache team was present during that discussion :-).

As you said, Apache httpd essentially uses the old syntax (and violates
the new syntax in two places!) to accommodate space-padding (at least):

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

I know Squid and several ICAP agents that use HTTP parsers do similar
things.


>  [ICAP, by the way, is not HTTP.]

ICAP is not HTTP but it explicitly uses big parts of HTTP syntax.
AFAICT, such IETF protocol reuse is a good thing and should be
encouraged and protected by IETF. If an HTTP*bis* RFC invalidates HTTP
syntax very prominently used in another IETF RFC, something went wrong.
Errata can fix that.


> 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.  

Both choices break things. The HTTPbis choice to delete LWS in chunks
breaks things today with a likelihood of 100% (my errata was inspired by
a real-world bug report related to this change). When HTTPbis is fixed,
someday, somewhere an implementation will misinterpret that whitespace.

Since that whitespace does exist in real messages, breaks ICAP RFC, and
causes no known specific harm, we ought to undo this syntax change IMO.


> I don't want to play errata ping pong.

The WG can always deny responsibility and add BWS instead of restoring
OWS. BWS cannot cause errata ping pong AFAICT. BWS does screw ICAP, but
nobody likes that kid anyway ;-).


Thank you,

Alex.



>>> On 14 Apr 2016, at 2:36 AM, Willy Tarreau <[e-mail]> 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 <[e-mail]>
>>>>
>>>> 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 ] )