Re: Translating CR LF to HTTP/1 headers

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