- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Tue, 25 Aug 2015 20:50:40 +0000
- To: Mark Nottingham <mnot@mnot.net>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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