RE: Line-folding in HTTP/2

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/

Received on Tuesday, 25 August 2015 20:51:09 UTC