Re: #541: CONTINUATION

>
> “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.”
>

Lol, can we add this error code? Please? /jk

Agreed. The concept of pre-announcing request and response header limits
seems... messy to me. I don't know what it means if I have a request who's
header size is larger than the limit. What do I do with that? I can't
reasonably "trim" the headers without deeper application knowledge: they
are what they are. How do I surface that error to the user, and what are
they supposed to do about it? For that matter, how does the remote endpoint
discover the impact the setting is having on actual clients? I'd rather
just optimistically fire off the request as I do now, and let the remote
endpoint be the arbiter of whether it's over limit.

It also seems problematic to announce to a potentially-malicious host
exactly how much they can get away with before DoS mitigation starts
kicking in.



> 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.)
>


This is a concern. I don't think it's at all desireable to have a part of
the spec which is designed to rarely be used. The risk of incorrect
implementation is too high.

Chromium will fully abide by whatever this working group decides, but right
now h2-13 is the implementation draft, and to ensure that CONTINUATION is
properly covered in h2-13 Chromium will emit them at smaller payload sizes.
This will be contentious for some, and I apologize for that, but the
alternative of an untested CONTINUATION frame is worse.


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

Agreed. If moving this flag makes CONTINUATION significantly more
palatable, I've no objections.




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