Re: [Technical Errata Reported] RFC7230 (4667)

Don't confuse the various lenient ways in which implementations parse HTTP with the requirements on generating HTTP messages that are defined by the ABNF. The ABNF is intended to be more restrictive. 

The scope of what Apache allows was reduced recently for security reasons, and I expect it to be reduced further the next time I get a chance to test and commit. Do not depend on such lenient parsing to exist in the future.  In many cases, we have just been waiting for RFC7230 to age enough before reducing the code substantially.

Likewise, don't confuse the parsing of ICAP messages (which are entirely defined by ICAP and its normative references) with requirements of RFC7230. If you need an exception, all you have to do is add it to ICAP  when (or if) that spec is updated to refer to RFC7230. ICAP hasn't changed until it does.

And, no, it is NEVER a good idea for new IETF protocols to effectively alias other IETF protocols. That has been proven many times by the three protocols that forked HTTP instead of just defining extensions within HTTP. Reuse of code in unexpected ways is just one of many problems that result.

....Roy


> On Apr 14, 2016, at 3:58 PM, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> 
>> 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 <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 ] )
>

Received on Thursday, 14 April 2016 22:40:12 UTC