- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Sat, 22 Aug 2015 19:44:21 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <BN3PR0301MB12495AD4C0185AA1F9DE17DE87640@BN3PR0301MB1249.namprd03.prod.outlook.>
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.
Received on Saturday, 22 August 2015 19:44:52 UTC