- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 26 Aug 2015 09:41:26 +1000
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 Tuesday, 25 August 2015 23:41:57 UTC