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

Header fair share, Was: Our Schedule

From: Greg Wilkins <gregw@intalio.com>
Date: Mon, 26 May 2014 16:35:10 +0200
Message-ID: <CAH_y2NHnrq9nGWRGeQGTQASA-EMUhS1GRVa+8NYEXx6O7J4XtQ@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 26 May 2014 16:07, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> On Mon, May 26, 2014 at 8:35 PM, Greg Wilkins <gregw@intalio.com> wrote:
> ​Flow control is not a mechanism to enforce fair share of the connection.
> ​Read http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-5.2.2
> ​
You may quibble with my use of the word "fair" to summarise flow control,
but the crucial words from 5.2.2 are:

 "Flow control addresses cases where the receiver is unable process data on
one stream,
 yet wants to continue to process other streams in the same connection."

unsegmented non flow controlled headers prevent progression on another

> ​Server and intermediaries can respond 431 if incoming headers are too
> large and refuse to forward to the shared backend connection.

Note that I'm fearful that clients and servers will collude, so that would
leave it to intermediaries to police stream header size limits.     If
intermediaries are required to enforce such limits, then we will lose
control over the maximum size of header than can be sent and negotiation
between endpoints will not help.

This is similar to the situation that exists to day with doing AJAX long
polling over HTTP/1.1.  There is no way of knowing what timeouts
intermediaries will apply so you have to guess a timeout that is long...
but not too long...

> Receiving CONTINUATION forever is unrealistic situation.
Then why does the protocol go to such complex lengths to support it?


Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Monday, 26 May 2014 14:35:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC