W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Translating CR LF to HTTP/1 headers

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 3 Sep 2013 11:24:56 -0700
Message-ID: <CABkgnnUSQm0hAMRrZtKrDBiNjkO9TjTwALkANLgqz4nERsjjsQ@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC