Re: Line-folding in HTTP/2

We (i.e. Akamai) are leaning towards coalescing the obs-fold into one more spaces for http/1.1 to http/2 translation as recommended by the old http/1.1 spec (I was told that this was a recommendation for http/1.0 spec too). This would avoid having folded headers as part of http/2 headers and still be backward compatible with old http/1.1. I do agree with Mike Bishop that h2 parsers need to basically be consistent in rejecting the obs-fold headers.

- Saurabh Kulkarni

From: Amos Jeffries <squid3@treenet.co.nz<mailto:squid3@treenet.co.nz>>
Date: Monday, August 24, 2015 at 8:56 AM
To: "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: Line-folding in HTTP/2
Resent-From: <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Resent-Date: Monday, August 24, 2015 at 8:57 AM

On 24/08/2015 8:24 p.m., Cory Benfield wrote:
On 22 August 2015 at 20:44, Mike Bishop 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.

If we are just mandating the reject option from the list mentioned in
RFC 7230 then the requirement is status code 400. Since its likely
coming from a 1.1 client via a broken gateway that is still reasonable.

If an explanation is desired the only choice is a canned 400-status
response with payload explaining. Simply closing the stream with that as
if it were a normal h2 completion. The error and problems are all in the
message layers outside the h2 itself anyway.


RST_STREAM vs GOAWAY is purely an HTTP/2 optimization for this error in
teh case where no explanation is desired. Selection of which is based on
criteria unrelated to the error itself. Which one gets sent (if either)
should follow the same choice made on any other h2 error.

If a 1.1 gateway is actually involved it should be mapping
PROTOCOL_ERROR on either of RST_STREAM or GOAWAY to a 400 status anyway.
So it does not matter really - all three options result in roughly the
same thing. Senders choice as to what side effects they want to see
happen, which comes back to that RST/GOAWAY selection algorithm being
generic.


>From a proxy/gateway perspective it would be more beneficial if servers
used RST_STREAM or the canned response. So only the one stream was
affected. But GOAWAY is also good - after all it is the h2 proxies or
gateways job to filter this out first.

Amos