Re: Striving for Compromise (Consensus?)

To be clear, I'm not actually suggesting we do this (there are parts I
like, but it's more complexity), but I do think something like it is needed
if header fragments may be interleaved. Otherwise proxies must use max
stream concurrency as their only lever to bound memory exhaustion attack
surface.


On Fri, Jul 11, 2014 at 1:08 PM, Johnny Graettinger <
jgraettinger@chromium.org> wrote:

> In order to flow control HEADERS we'd have to add an expanded BLOCKED
>> frame that lets the sender inform the receiver that it is blocked on a
>> stream with a non-0 window_size and include how many extra bytes the
>> window_size needs to be increased in order to fit the frame.
>>
>
> Yep. Or allow the non-indexed-literal-with-a-literal-name opcode (only) to
> span HEADER/CONTINUATION frame boundaries (which would also allow single
> large header values to be fragmented across smaller frames).
>
> Addressing the larger proposal: If we flow control HEADERS, or even just
> allow the interleaving of header block fragments, we probably also want to
> re-work the stream concurrency limit mechanism of the protocol. Requiring
> :headers up-front is nice, but not really sufficient (consider a proxy
> routing on a session cookie). It also doesn't play well with flow-control
> (what if the session window is too small to send all :headers?).
>
> I think we'd want a "has the remote endpoint accepted this stream?" bit of
> stream state, and a protocol setting limiting the number of unaccepted
> streams an endpoint may create. That would allow a connection to multiplex
> large numbers of accepted streams, while limiting the memory exhaustion
> attack surface a proxy must present. A proxy would only "accept" a stream
> once it has an established upstream route through which it can immediately
> forward header fragments & data. A straw-man mechanism might be that a
> stream is accepted upon receipt of a HEADERS or PRIORITY frame.
>
> Such a setting would likely replace the current
> SETTINGS_MAX_CONCURRENT_STREAMS, as an endpoint can implicitly enforce that
> setting by deferring stream acceptance.
>