- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Mon, 24 Aug 2015 09:24:59 +0100
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 22 August 2015 at 20:44, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > 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. Presumably the rule would be that any header containing an octet string that matches the regex '\r?\n[ \t]' is treated as invalid (PROTOCOL_ERROR). That's reasonable enough. What is the proposed rejection? RST_STREAM for the given stream? GOAWAY? Should we consider adding a new error code to handle this case for ease of debugging? Are intermediaries expected to also reject the stream, or should they simply strip the whitespace from the folded line? I'm not opposed to this in principle, but I'd like to see it fleshed out a bit.
Received on Monday, 24 August 2015 08:25:28 UTC