Re: Translating CR LF to HTTP/1 headers

It's very important to note that the grammar rules for existing
headers have not yet been changed for 2.0. The typed codecs introduce
possible changes that could deal with this fairly easily, but so long
as we're using the existing definitions, U+10/U+13 are handled exactly
as Julian describes. If they are encoded in some way (i.e. RFC5987)
then they are handled as just part of the value, if they are encoded
specifically as U+10/U+13 then they're obs-fold.

- James

On Tue, Sep 3, 2013 at 11:24 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
>[snip]
> This is an important point, and I'll have to lean on Julian's
> expertise for this one, since he knows the header encoding mess better
> than I.  A value can include U+13 and U+10, but only if they are
> escaped using the encoding described in RFC5987.  Any U+10 or U+13
> that appears in the value of a header field is therefore part of
> obs-fold, and can be replaced by SP.  We're saying here that it MUST
> be replaced by SP.
>
> I don't think that any grammar permits CR/LF as anything other than as
> part of obs-fold.  e.g.,
> http://tools.ietf.org/html/rfc2616#section-2.2, which specifically
> says:
>
>    [...] A CRLF is allowed in the definition of TEXT only as part of a header
>    field continuation.
>
> httpbis is much stricter about obs-fold:
> tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#section-3.2.4
>

Received on Tuesday, 3 September 2013 21:11:37 UTC