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

Re: HEADERS and flow control

From: Michael Sweet <msweet@apple.com>
Date: Wed, 21 May 2014 10:32:25 -0400
Cc: David Krauss <potswa@gmail.com>, Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <F3F2A187-B35F-483C-8358-FE4381BB415D@apple.com>
To: Greg Wilkins <gregw@intalio.com>
+1

Even with the current header compression, there is no reason to prevent intervening DATA frames, or to omit HEADER frames from the scheduling/queuing algorithms that clients and servers must implement for HTTP/2.  The only requirement based on the header compression algorithm that has been adopted is that there can only be a single set of HEADER frames in flight in either direction, and I don't think that is a big step beyond what is already required.


On May 21, 2014, at 9:50 AM, Greg Wilkins <gregw@intalio.com> wrote:

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


Received on Wednesday, 21 May 2014 14:32:57 UTC

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