RE: Connection limits

I believe the state of the mainstream browsing world today is:

Opera enables pipelining by default.  They have a TON of code which attempts to detect incompatibility on the route to the server and disables pipelining if such problems are detected.
Firefox supports pipelining but disables it by default.  For the latest build of Firefox3, they have enabled pipelining to only HTTPS servers by default, under the theory that doing so is less likely to break compatibility as the CONNECT tunnel prevents proxies from detecting/breaking on pipelined requests.
Internet Explorer does not support pipelining.
All major browsers support persistent connections for HTTP/1.1, and for HTTP/1.0 with appropriate Keep-Alive directives.

Other tidbits:
IIS and Apache both support pipelining.  ISA proxies accept pipelined requests but queues them locally and does not pipeline to origin servers.  The System.NET HTTP stack supports pipelining (WinINET and WinHTTP do not).

Eric Lawrence
Program Manager
Internet Explorer - Security
________________________________
From: ietf-http-wg-request@w3.org [ietf-http-wg-request@w3.org] On Behalf Of Adrien de Croy [adrien@qbik.com]
Sent: Wednesday, March 05, 2008 1:05 PM
To: Roy T. Fielding
Cc: Josh Cohen (MIG); David Morris; Mark Nottingham; ietf-http-wg@w3.org Group
Subject: Re: Connection limits



I agree

If pipelining is sending another request on a connection before you get
a response, then as far as I can tell, all the major browsers by default
do it.

And I don't think it makes any sense to try and come up with a magic
number for connections.  The TCP overhead is a lot lower now with
persistent connections which are now ubiquitous, so maybe the
requirement for many connections is reduced, but policy decisions like
that should be left to server or proxy admin/management (people), not
hard coded into software or written into specs.

Adrien


Roy T. Fielding wrote:
>
> On Mar 5, 2008, at 4:52 AM, Josh Cohen (MIG) wrote:
>> I would agree.
>>
>> The connection limit, in addition to the bandwidth limitations of the
>> time, also helped the servers themselves.  Back then, maintaining
>> many simultaneous but short lived TCP connections was inefficient for
>> many operating systems TCP stacks.  By switching to fewer, longer
>> standing connections, and the hope of the use of pipelining, we
>> thought we'd address that.
>> Nowadays with stacks much more efficiently tuned to handle these
>> types of connections efficiently, and the non-occurrence of
>> pipelining, I think this could be relaxed a bit.
>
> Just out of curiosity, why do people keep saying things like
> "non-occurrence
> of pipelining" when the vast majority of connections I've looked at over
> the past six years contain obviously pipelined GET requests and
> occasional
> pipelines of POST (in spite of the bogus requirement).  Is this just
> because
> you do all your work behind a corporate firewall proxy?  Is this just
> another myth?  Or am I the only one on the planet who looks at traces to
> servers using both a client and a server that support pipelining?
>
> Er, in regards to the topic, I see no reason for the connection limits.
> They should be replaced with a simple statement of why too many
> connections
> results in counterproductive collision/bandwidth effects.
>
> ....Roy
>
>

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com<http://www.wingate.com/>