Re: Line-folding in HTTP/2

> Note that it references field-content, whose ABNF doesn't allow CR or LF.

I agree with the intent of this part of the HTTP/2 spec but the problem we
are facing is that the spec does not clearly say how to *safely* translate
requests coming from a sender which was potentially written before RFC
7230 came into being. And for us (Akamai) that is really important because
any error response on HTTP/2 to a request that works fine on HTTP/1 posses
risks for customer traffic.

I think if we were to add that obs-fold MUST be replaced by a space when
translating from HTTP/1 to HTTP/2 would make it much more safer for us.
For obvious reasons we will anyways do it but just thought of asking is
such a correction is possible and if other people might be interested in
this too.

Shakesh

On 8/25/15, 4:43 PM, "Mike Bishop" <Michael.Bishop@microsoft.com> wrote:

>There we go -- thanks for finding that!
>
>-----Original Message-----
>From: Mark Nottingham [mailto:mnot@mnot.net]
>Sent: Tuesday, August 25, 2015 4:41 PM
>To: Mike Bishop <Michael.Bishop@microsoft.com>
>Cc: ietf-http-wg@w3.org
>Subject: Re: Line-folding in HTTP/2
>
>Indeed, I forgot that we already covered this:
>
><http://httpwg.github.io/specs/rfc7540.html#rfc.section.10.3>
>
>"""
>Similarly, HTTP/2 allows header field values that are not valid. While
>most of the values that can be encoded will not alter header field
>parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and
>the zero character (NUL, ASCII 0x0) might be exploited by an attacker if
>they are translated verbatim. Any request or response that contains a
>character not permitted in a header field value MUST be treated as
>malformed (Section 8.1.2.6). Valid characters are defined by the
>field-content ABNF rule in Section 3.2 of [RFC7230].
>"""
>
>Note that it references field-content, whose ABNF doesn't allow CR or LF.
>
>
>> On 26 Aug 2015, at 6:50 am, Mike Bishop <Michael.Bishop@microsoft.com>
>>wrote:
>> 
>> Implementations might not be required to reject it, but I'd argue that
>>implementations should be permitted to reject it in HTTP/2.  No one is
>>hand-typing a request with HPACK.  Stripping it out should be a normal
>>part of preparing to HPACK-compress headers before you send them -- if
>>not required by the standard, at least de facto in all the major
>>implementations.  That goes back to the discussion of seeing the
>>multiplexing layer as a 1.1/2 intermediary.
>> 
>> Servers and intermediaries are already allowed to be intolerant in the
>>HTTP/1.1 spec -- I think HTTP/2 is the right time for user agents to
>>also choose to reject this behavior.  Maybe it's not time to mandate it
>>in a spec, or rather maybe it's too late to get it into the HTTP/2 spec,
>>but it's a good time to further extinguish this through market action so
>>we can fully remove it from the spec next time around.
>> 
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mnot@mnot.net]
>> Sent: Monday, August 24, 2015 6:10 PM
>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>> Cc: ietf-http-wg@w3.org
>> Subject: Re: Line-folding in HTTP/2
>> 
>> I think so. We deprecated folding, but couldn't require implementations
>>to reject it, because (as you've seen) it still happens in the wild.
>> 
>> A later version of HTTP might be able to introduce a stronger
>>requirement about rejecting it. H2 isn't that version, though.
>> 
>> Cheers,
>> 
>> 
>> 
>>> On 25 Aug 2015, at 11:04 am, Mike Bishop
>>><Michael.Bishop@microsoft.com> wrote:
>>> 
>>> So the argument would be that clients should be more permissive and
>>>un-fold based on that guidance?
>>> 
>>> -----Original Message-----
>>> From: Mark Nottingham [mailto:mnot@mnot.net]
>>> Sent: Monday, August 24, 2015 5:07 PM
>>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>>> Cc: ietf-http-wg@w3.org
>>> Subject: 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/
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>
>--
>Mark Nottingham   https://www.mnot.net/
>

Received on Wednesday, 26 August 2015 00:28:08 UTC