Re: #541: CONTINUATION

The limit on max header size partially solves a problem (see other thread
for the problems with how a proxy picks the right max size..) that is
different from the jumbo vs continuation stuff, though.
The limit on max frame size absolutely helps to make multiplexing work (and
I can get behind that).

I see a few distinct and orthogonal topics:
1) declaring a limit on the compressed header size
2) headers get buffered at sender until complete and sent with declared
length
3) declaring a maximum accepted frame size for headers or data frames or
perhaps all frames.
4) changing the base framing format to have a larger, but consistent size
field (e.g. from 16 bits to 24).
5) changing the base framing format to have a variable length size field
6) headers transmitted using multiple frames (i.e. continuations)
7) moving the flags on continuations to the last frame, possibly renaming
those/changing the opcodes
8) nonblocking headers
9) flow control for metadata (i.e. headers).

A few of these get conflated often (e.g. 1,2,{4,5}), despite the fact that
they're separable.

I'm saying this in the hope that we can talk about these separately.
>From my perspective:
#1: Sure, though I suspect its utility will be minimal when
proxies/gateways are in the mix.
#2: Don't like it-- it restricts implementations in ways that affect their
performance/efficiency without providing clear DoS-protection/scaling
benefit.
#3: Sure, seems reasonable to do.
#4: Fine, so long as #3 covers data and headers, though I suspect that
adding to the size field will increase protocol overhead in the common
case, and that a 16 bit length field is good enough for that common case.
#5: Don't like it, never will. It makes base framing more complicated, and
the base framing should be the simplest and most regular thing in the
protocol. Interpretation can have more complexity-- framing shouldn't.
Getting the framing wrong leads to security nightmares.
#6: I prefer fragmentation to varying the base framing due to the reasons
described in #5.
#7: Sure. We could also do PARTIAL_HEADERS* HEADERS, or HEADERS
CONTINUATION*, or SYN_STREAM (HEADERS)* END, whatever. All make just as
much sense to me as the current layout.
#8: Still for it, though it does add complexity. Probably not worthwhile to
solve the problem for HTTP-for-browsing, but useful for other usecases
where HTTP would be used.
#9: Same as #8.


-=R


On Mon, Jul 7, 2014 at 5:11 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jul 7, 2014, at 5:38 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> > You're conflating things.
> > Timeouts when receiving metadata/headers is an issue regardless of the
> use large frames or continuations, as a promise of X bytes (or a complete
> header) doesn't mean it will actually happen, or that it will happen in a
> reasonable period of time.
> > This is an issue with both large frames and continuations. It is not
> limited solely to continuations.
>
> The promise is significantly easier to meet though because its limited,
> especially by default where the limit is 16K. You can of course still have
> a total connection stall, but that affects all streams anyway. What the
> limit does is improve the quality of the multiplexing.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>