Header fair share, Was: Our Schedule

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



> ​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?

regards


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