Re: Striving for Compromise (Consensus?)

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