- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 26 Aug 2015 10:32:50 +1000
- To: "Jain, Shakesh" <shjain@akamai.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> 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