Re: Our Schedule

On Mon, May 26, 2014 at 8:35 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
>>
>> >       • Users of the protocol, are able to send data as headers, which
>> is unconstrained by size, flow control or segmentation.   Client-side and
>> Server-side applications are bound to collude to exploit this to obtain an
>> unfair share of any shared HTTP/2 connections/infrastructure, which will
>> eventually break the fundamental paradigm around which the protocol is
>> based and eventually force the use of multiple connections again.
>>
>> Can you explain this a bit more, perhaps with an example?
>>
>>
> A core aspect of HTTP/2 is about fairly sharing a single HTTP connection.
> In the initial usage, this is envisioned to be shared by streams from the
> one web application, but there will also be wider sharing: between tabs on
> a browser talking to the same service; between streams from different
> clients aggregated onto a connection by an intermediary.   But data sent as
> headers rather than in data frames is not subject to the fair share
> mechanisms.  It is not flow controlled, nor can it be segmented and
> interleaved with data from other streams.
>
>
​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​



>  Thus if there is contention for shared connections, then a huge incentive
> exists for to utilise headers for data transfer rather than data
> frames.      Initially application access to this is somewhat limited by
> the browsers and to some extend by server header limits.    But we have
> already seen that browsers are prepared to abuse the RFC to gain
> performance advantages over competitors (see the connection limit arms
> race) and browser/server venders are not the only gatekeepers for access to
> shared infrastructure. If the incentive exists, then it is possible and
> likely developers will create clients and servers that will collude to send
> their applications data via headers rather than by data frames, so that
> they may gain an unfair share of any common connections.
>
> Simply put, one user may grab exclusive use of the entire HTTP/2
> connection capacity by sending a HEADERS frame an then continuing to stream
> data in headers encoded as CONTINUATION frames forever.
>
>
​Server and intermediaries can respond 431 if incoming headers are too
large and refuse to forward to the shared backend connection. Receiving
CONTINUATION forever is unrealistic situation.

Best regards,
Tatsuhiro Tsujikawa​