Re: Translating CR LF to HTTP/1 headers

On 2013-09-03 17:53, Tatsuhiro Tsujikawa wrote:
>
>
>
> On Wed, Sep 4, 2013 at 12:47 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto: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?

Actually, to SP. See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-23.html#rfc.section.3.2.4.p.6>:

"A proxy or gateway that receives an obs-fold in a response message that 
is not within a message/http container MUST either discard the message 
and replace it with a 502 (Bad Gateway) response, preferably with a 
representation explaining that unacceptable line folding was received, 
or replace each received obs-fold with one or more SP octets prior to 
interpreting the field value or forwarding the message downstream.

A user agent that receives an obs-fold in a response message that is not 
within a message/http container MUST replace each received obs-fold with 
one or more SP octets prior to interpreting the field value."

Best regards, Julian

Received on Tuesday, 3 September 2013 16:46:26 UTC