Re: [Technical Errata Reported] RFC7230 (4189)

[Zhong Yu <[e-mail]>]

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
>