Re: Translating CR LF to HTTP/1 headers

On 3 September 2013 08:31, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> So if U+10 and/or U+13 are included in HTTP/2 headers, what
> should intermediary do to translate them into HTTP/1?  Just
> remove them or replace them with safe characters? The meaning of
> the headers may change with these changes, especially if those
> characters are permitted in HTTP/2 headers.  Returning 5xx
> response may be an option. But there is very interesting
> situation. If all machines in the path are HTTP/2, then the
> request succeeds, but if one of them is HTTP/1 then request
> fails.

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 18:25:28 UTC