Re: #541: CONTINUATION

[Trimmed CC]

Speaking from the perspective of working on both Firefox (client) and (more
recently) node-http2 (server) implementations, I strongly prefer keeping
the status quo. I have seen no arguments at this point that convince me
that a relatively large change to how we compress and frame headers is in
any way required. We're talking about handling (iirc) 0.02% of the cases
here, and I frankly think it makes sense to say that if you've received
more compressed (or uncompressed!) headers than you're willing to deal
with, then just send a RST_STREAM and process and discard any remaining
HEADERS/CONTINUATION frames on that stream (or send a GOAWAY if you feel
you're in a DoS situation). It seems to me that a robust implementation
will already have a facility to process and discard HPACK data anyway, to
handle other situations where you may decide while receiving headers that
you don't want the stream.

I *could* work with stateless CONTINUATION frames in both of these
implementations, though it would still require rolling back the state of at
least one encoded header (once it's determined that the encoding would
cause a crossing of the 16k boundary). It also breaks the separation of
concerns between HPACK and the framing layer in a way that I find
*significantly* less than appealing. As such, even though I won't burn
things down if this is the option the WG comes to consensus on, I won't go
down without a fight :) To be clear, there is nothing in my server-side
implementation experience that has indicated to me that even this
alteration is necessary, or even a nice-to-have.

None of the other options are acceptable to me.
--
Peace,
  -Nick


On Wed, Jul 2, 2014 at 4:12 AM, Mark Nottingham <mnot@mnot.net> wrote:

> <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/
>
>
>
>
>