W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Striving for Compromise (Consensus?)

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Fri, 11 Jul 2014 13:08:28 -0400
Message-ID: <CAEn92TpjODpE+BCtP8xR7=G607gFqv7DLKHoH60exzwUz+Y2DQ@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> 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.
Received on Friday, 11 July 2014 17:08:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC