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

Re: Translating CR LF to HTTP/1 headers

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 4 Sep 2013 00:53:02 +0900
Message-ID: <CAPyZ6=K0Zpxhv7oZsbyap7ha0DA9533OO3TXWsx3uf6yXskArA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Sep 4, 2013 at 12:47 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-09-03 17:31, Tatsuhiro Tsujikawa wrote:
>> In http://http2.github.io/http2-**spec/#rfc.section.10.3<http://http2.github.io/http2-spec/#rfc.section.10.3>
>> """
>> An intermediary that performs translation into HTTP/1.1 cannot
>> alter the semantics of requests or responses. In particular,
>> header field names or values that contain characters not
>> permitted by HTTP/1.1, including carriage return (U+10) or line
>> feed (U+13) MUST NOT be translated verbatim.
>> """
>> 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.
> CR and LF *are* allowed in HTTP/1.1 field *values* (not names), as per the
> OBS-FOLD ABNF production. (<http://greenbytes.de/tech/**
> webdav/draft-ietf-httpbis-p1-**messaging-23.html#header.**fields<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-23.html#header.fields>
> >)
Does it mean that intermediary should translate CR and LF in the HTTP/2
field-value to OBS-FOLD sequence?

Best regards,

Tatsuhiro Tsujikawa
Received on Tuesday, 3 September 2013 15:53:49 UTC

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