- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 22 Apr 2015 06:31:25 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- 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>
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 04:32:06 UTC