Re: Line-folding in HTTP/2

> On 23 Aug 2015, at 5:44 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> We’ve encountered a site (whom we shall leave nameless, unless they choose otherwise) that included a 0x0A20202020202020 sequence inside an HPACK value –carriage return followed by several spaces, which is to say line-folding.  Edge rejects that (as will IIS if clients send it), because that’s an HTTP/1.1 legacy artifact.  RFC 7540 just references RFC 7230 section 3.2 for header values, which in turn says in section 3.2.4:
>    Historically, HTTP header field values could be extended over
> 
>    multiple lines by preceding each extra line with at least one space
> 
>    or horizontal tab (obs-fold).  This specification deprecates such
> 
>    line folding except within the message/http media type
> 
>    (Section 8.3.1).  A sender MUST NOT generate a message that includes
> 
>    line folding (i.e., that has any field-value that contains a match to
> 
>    the obs-fold rule) unless the message is intended for packaging
> 
>    within the message/http media type.
> 
>  
> While there’s no requirement for HTTP/1.1 clients to reject this pattern (for back-compat), it seems like an HTTP/2 implementation might want to hold its peers to that MUST NOT.  Osama has additionally pointed out that being tolerant of this could make HTTP/1.1 to HTTP/2 conversion “wreak havoc and bugs.”  In an offline thread with a few others, the general feeling seems to be that we should all change to reject this as broken header framing.
>  
> Does anyone have objections and think this should be tolerated by an h2 parser?  If not, I don’t know that this qualifies as an erratum, but it would be nice to officially preserve this somewhere.

Reading a bit further down:

"""
A server that receives an obs-fold in a request message that is not within a message/http container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.

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.
"""

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 25 August 2015 00:07:24 UTC