- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 21 Apr 2015 10:48:53 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "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>
I'll suggest the following fix:
header-field = field-name ":" OWS field-value OWS
field-name = token
* field-value = [ field-content *( obs-fold field-content ) ]
* field-content = field-vchar [ *( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text
* obs-fold = OWS CRLF 1*( SP / HTAB )
"field-content" spans a whole line, without leading/trailing spaces,
and contains at least one visible char.
This will force message producers to apply folding reasonably.
And if by using this stricter grammar, a message parser rejects a
production that was previously accepted, it might not be a bad thing
either - the production is practically ambiguous and invites different
interpretations.
Zhong
On Tue, Apr 21, 2015 at 10:24 AM, Zhong Yu <zhong.j.yu@gmail.com> 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.
>
> RFC 822 $3.2 appears to suggest the same thing, that obs-fold can only
> appear between two non-empty segments.
>
>
> Zhong
Received on Tuesday, 21 April 2015 15:49:20 UTC