Re: [Technical Errata Reported] RFC7230 (4667)

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

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

I fully agree, but we are not discussing ABNF creation IMO. We are
discussing a syntax change by an HTTPbis RFC. To change HTTP/1 syntax
that has been in use for many years, the "Founders Intent" alone is not
enough IMHO. There must be other compelling reasons. The only other
reason given so far was "lack of known examples", followed by your
discussion of "space padding" as a known usage example. I expect the bar
for HTTP/1 syntax change to be significantly higher.

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

AFAICT, the core of our disagreement is that you are treating RFC 7230
as a new protocol, not an HTTPbis document that polishes and clarifies
HTTP/1 while avoiding unnecessary breaking changes. If HTTP/1 defined by
RFC 7230 is a new protocol, then my ICAP defense plea is indeed invalid
(all other reasons to add OWS or at least BWS remain).

> And, no, it is NEVER a good idea for new IETF protocols to
> effectively alias other IETF protocols.

AFAICT, ICAP does not alias HTTP. It uses RFC 2616 to define HTTP
messages. This is similar to RFC 7230 using URI definitions from RFC
3986. When URIbis obsoletes RFC 3986, I expect the authors to be very
careful not to accidentally invalidate HTTP/1 messages. IMHO, HTTPbis
should offer the same courtesy to ICAP.

Thank you,

P.S. Please do not misinterpret the ICAP part of my argument as an
admiration for RFC 3507. I know that RFC has lots of problems. I am
thinking about ICAP developers that generally want to reuse HTTP/1
parsers. Such reuse now requires RFC 7230 violations and that feels
rather wrong [without compelling reasons for the syntax change].

>> On Apr 14, 2016, at 3:58 PM, Alex Rousskov <> 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 <> 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:
>>>>>> --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Alex Rousskov <>
>>>>>> 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 Friday, 15 April 2016 00:51:43 UTC