Re: #540: "jumbo" frames

hey all -


> Extensions are length limited to 16KB, so to allow that you would have to
> define special framing rules, and if you have done that might as well apply
> it everywhere.
>


I don't think that's the case at all. un-acked extensions are limited that
way because you can't change the semantics of the protocol.. but once you
ack something you can do anything you like - including changing framing to
look like websockets via use one of the R bits (as an example). Go
bootstrap h3 that way if you feel so inclined to write an extension like
that.

but maybe I have that wrong -(our extension text is brand new afterall) and
extensions are meant to preclude such hackery which seems odd - given they
are essentially a hackery escape hatch that already acknowledges the
ability to change semantics of existing elements. If that's true there is
always the alpn method of proving this can work - because I really don't
think it can work and leave h2 responsive.



> It’s a very common use-case.
>
>

unfortunately its one that is in direct competition with the driving reason
for h2: prioritized mux on one connection. Minimally you should prove out
that can coexist with jumbo frames because spdy showed us it was a problem.
You simply can't send a multi megabyte frame and also then respond quickly
to a CANCEL and a new GET on the same connection which is something any h2
implementation should be able to handle responsively. My H1 application
closes a ton of connections because of that pattern - h2 doesn't have to.
Its one of its under appreciated features. The cost of that feature, 16KB
frames, is reasonable imo.

and of course, then there is TLS.

ship it.