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

Re: HEADERS and flow control

From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 21 May 2014 15:50:04 +0200
Message-ID: <CAH_y2NGdg_znTPpdAeRYrEJL0xGAaJFoi=6g-JsGViDsKM45oA@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 21 May 2014 09:57, David Krauss <potswa@gmail.com> wrote:

> The user has no motivation to get around flow control.


Perhaps not today, but what about in 10 years time or 20 years time???

Plus, I can already consider situations where it is desirable now.  Any
time a HTTP/2.0 connection is used for shared traffic (perhaps from a
connection aggregator or even just multiple client tabs all accessing a
common host/service), then bypassing flow control can give an unfair slice
of the multiplexed channel.  Indeed not only are headers not flow
controlled, they cannot be interleave with other frames!

Finally, remember that the abuse that resulted in the break down of the two
connection limit might have started with application developers doing DNS
sharding, then got popular with users adjusting their browser
configurations, but it really only got cemented in place when the browser
vendors decided to unilaterally ignore the RFC. So any abuse of headers may
not come from user or application developers.

I remain convinced that un-flow controlled and non interleaved headers will
eventually be exploited to access unfair portions of shared resources.   I
find this an extraordinary risk to take just so we can support a specific
header compression algorithm.

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.
Received on Wednesday, 21 May 2014 13:50:37 UTC

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