Re: [Technical Errata Reported] RFC7230 (4189)

[Zhong Yu <[e-mail]>]

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 <[e-mail]> 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