Re: Line-folding in HTTP/2

> On 26 Aug 2015, at 10:27 am, Jain, Shakesh <shjain@akamai.com> wrote:
> 
>> 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.

That's already specified in 7230.


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

Hopefully, all of this will be a little less convoluted once we update the 723x series to Full Standard.

Cheers,

> 
> 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/
>> 
> 

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

Received on Wednesday, 26 August 2015 00:33:21 UTC