- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 22 Apr 2015 08:55:06 -0500
- To: Willy Tarreau <w@1wt.eu>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "Roy T. Fielding" <fielding@gbiv.com>, Barry Leiba <barryleiba@computer.org>, RFC Errata System <rfc-editor@rfc-editor.org>, Pete Resnick <presnick@qti.qualcomm.com>, Mark Nottingham <mnot@mnot.net>, Simon Schüppel <simon.schueppel@googlemail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 <w@1wt.eu> 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 >
Received on Wednesday, 22 April 2015 13:55:33 UTC