Re: [Technical Errata Reported] RFC7230 (4189)

[Barry Leiba <[e-mail]>]

Interesting, and thanks for testing that.

Regardless of whether the change you propose is a good idea or not, I
think it does not fall under "errata".  It'd be a change we'd have to
consider as we advance the HTTP 1.1 specs to Internet Standard... but
in this regard, the current documents do say what they were intended
to.

I'm going to go ahead and mark this errata report "Verified" with
Julian's latest edit.  And thanks, everyone, for taking the time to
sort this out.

Barry

On Wed, Apr 22, 2015 at 9:55 AM, Zhong Yu <[e-mail]> wrote:
> Well, Willy you are right that we cannot change a rule that has been
> in effect for 20 years. If a parser doesn't follow the rule, it is a
> bug, and it needs to be fixed.
>
> Out of curiosity, I constructed the following response, and tested on
> 5 major browsers
>
> HTTP/1.1 200 OK\r\n
> Connection: close\r\n
> Content-Type: text/plain;charset=UTF-8\r\n
> <SP>\r\n
> Server: test-folding\r\n
> \r\n
> 123456789
>
> IE displays the response as
>
> Server: test-folding\r\n
> \r\n
> 123456789
>
> That doesn't seem right.
>
> Zhong Yu
> bayou.io
>
>
>
>
> On Tue, Apr 21, 2015 at 11:31 PM, Willy Tarreau <[e-mail]> wrote:
>> On Tue, Apr 21, 2015 at 10:24:47AM -0500, Zhong Yu wrote:
>>> Another question about obs-fold before we proceed with the formal
>>> definitions. Consider the following example
>>>
>>> foo: bar<CRLF>
>>> <SP><CRLF>
>>> ...
>>>
>>> It won't be surprising if some parser mistakes the 2nd line as an
>>> "empty line" that terminates the headers. Visually it *is* an empty
>>> line.
>>>
>>> In spirit, obs-fold should be followed by visible chars, otherwise
>>> it's very confusing and problematic.
>>
>> I disagree, a parser doesn't "see" characters, it consumes them. Here
>> you have a space after a CRLF, so it's a continuation of a folded header,
>> that's as simple as that. And it's important that it's properly defined
>> so that it's not abused by senders trying to put parsers in a situation
>> which is not well defined.
>>
>>> RFC 822 $3.2 appears to suggest the same thing, that obs-fold can only
>>> appear between two non-empty segments.
>>
>> And what is the parser supposed to do if it receives something which does
>> not match this rule ? That's always the problem when adding exceptions to
>> well-defined rules, it requires more work on the recipient side to properly
>> handle the situation. In short, it *adds* more risks of confusion.
>>
>> Regards,
>> Willy
>>