Re: #541: CONTINUATION

Our preference lies somewhere between #0 and #4.  We feel like the drawbacks of CONTINUATION, while they certainly exist, are just as present in any of the other proposals.  We haven’t seen a compelling reason that another proposal is substantially better in a way that justifies an invasive change.  CONTINUATION is effectively a jumbo frame scoped only to headers -- as they should be, since there is implementation data suggesting that jumbo data frames hurt in the normal case.

It shouldn’t require an extension to relay a valid HTTP/1.1 request over HTTP/2.  That makes either solution as an extension a non-starter for us.  That said, there are smaller changes that could possibly improve the situation.

HTTP semantics already have the concept of rejecting a request because the request headers are too large; making this more transparent to the client by optionally pre-announcing these limits and allowing intermediaries closer to the client to fail the request sooner is an improvement that doesn’t change semantics.  However, the concept of limiting response header size is new, and it’s unclear how an intermediary would reasonably handle this -- “Your request was fully processed, possibly changing state, but I won’t tell you what the outcome was because it’s bigger than you can receive. RST_STREAM YOU_CANT_HANDLE_THE_TRUTH.”  What does that turn into on a /1.1 leg?  A client could not successfully retry the request in that situation.

Requiring that CONTINUATION only occur when the previous frame is max-size as a way to avoid abuse is certainly reasonable.  If that makes people more comfortable, let’s take it.  (That does make this code path even less frequently hit, though, and it’s therefore harder for Will to trigger it “just because” in his generous effort to assist with the testing of every HTTP product on the web.)

The one salient difference that I see between jumbo frames and CONTINUATION is that the recipient knows up front how big the blob is.  This could be addressed by including in a HEADERS/PUSH_PROMISE frame either the total size of the headers or the number of CONTINUATION frames which follow.  (This might be present only if END_HEADERS is not set, or could replace END_HEADERS.)

I frankly don’t care where the END_STREAM flag lives.  Flip a coin and let me know.

Sent from Windows Mail

From: Mark Nottingham<mailto:mnot@mnot.net>
Sent: ‎Wednesday‎, ‎July‎ ‎2‎, ‎2014 ‎4‎:‎12‎ ‎AM
To: HTTP Working Group<mailto:ietf-http-wg@w3.org>
Cc: Tatsuhiro Tsujikawa<mailto:tatsuhiro.t@gmail.com>, Mike Bishop<mailto:Michael.Bishop@microsoft.com>, Gábor Molnár<mailto:gabor.molnar@sch.bme.hu>, Patrick McManus<mailto:mcmanus@ducksong.com>, Shigeki Ohtsu<mailto:ohtsu@iij.ad.jp>, Stephen Ludin<mailto:sludin@akamai.com>, Johnny Graettinger<mailto:jgraettinger@chromium.org>, Hasan Khalil<mailto:hkhalil@google.com>, Jeff Pinner<mailto:jpinner@twitter.com>, block.rxckin.beats@gmail.com<mailto:block.rxckin.beats@gmail.com>, Adrian Cole<mailto:adrian.f.cole@gmail.com>, matsumoto_r@net.ist.i.kyoto-u.ac.jp<mailto:matsumoto_r@net.ist.i.kyoto-u.ac.jp>, Cory Benfield<mailto:cory@lukasa.co.uk>, Daniel Stenberg<mailto:daniel@haxx.se>, Flack, Martin<mailto:mflack@akamai.com>, t@motd.kr<mailto:t@motd.kr>, Greg Wilkins<mailto:gregw@intalio.com>, Jeroen de Borst<mailto:J.deBorst@F5.com>

<https://github.com/http2/http2-spec/issues/541>

There’s been strong pushback on the current design of CONTINUATION from some interested parties, and a few implementers. Despite the fact that this design is the result of multiple meetings demonstrating strong consensus, and the fact that we have a schedule-focused charter, this issue deserves a good hearing.

I think everyone now has an idea of the issues and trade-offs involved, as well as the potential end-games. We also helpfully have a few proposals on how to move forward:

0) the status quo

1) <https://github.com/http2/http2-spec/pull/544> and variants thereof (e.g., not including CONTINUATION in flow control; alternative syntaxes)

2) limiting header sizes to 16K (HPACK’d) in HTTP/2, as per PHK’s suggestion

There’s also another implicit option;

3) We can’t know until we get substantial interop and deployment experience with draft-13.

I’d like to ask the implementers (as identified on the CC: line) what their preferences are, and what they can’t live with. If there’s another option, please say so, but only if it’s materially different, and you believe it has a chance of achieving consensus.

To be clear, if you don’t say that you can’t live with something, it means that it’s an acceptable outcome. If you do, be prepared to back up such a strong stance with an equally strong argument.

Note that this is input to help determine consensus, not a vote.

Thanks,

P.S. Please keep in mind that (3) is not “wait until September, then decide it’s too late.” Achieving a reasonable consensus now is relatively pain-free, if possible; deadlocking right before we (want to) ship is something I want to avoid.

P.P.S. To anticipate some responses, a generic “jumbo frame” is off the table for this discussion; doing so doesn’t appear to have broad support, and there are strong arguments against it.


--
Mark Nottingham   http://www.mnot.net/