W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: [OT] Re: #131: Connection limits (proposal)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 20 Oct 2009 09:23:43 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A99D4B67-5072-4D73-A9C2-4BB58AC23220@mnot.net>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
I've been thinking the same thing for a while now, and would be  
willing to both work on a spec and get it into implementations.

I was thinking of using a new Keep-Alive token, e.g.,

   Keep-Alive: max-conns=...

but that's just syntax (mostly).

It's true that doing so is not in the current charter of HTTPbis, but  
there's no reason we can't work on a draft.

If you've been following the hybi list, there are some other things  
that may be interesting to work on too; e.g., the end-to-end max of  
various, more fine-grained timeouts than is currently available with  
Keep-Alive: timeout=...


On 20/10/2009, at 5:30 AM, William A. Rowe, Jr. wrote:

> Mark Nottingham wrote:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>
>> """
>> Clients (including proxies) SHOULD limit the number of simultaneous
>> connections that they maintain to a given server (including proxies).
>> Previous revisions of HTTP gave a specific number of connections as a
>> ceiling, but this was found to be impractical for many  
>> applications. As
>> a result, this specification does not mandate a particular maximum
>> number of connections, but instead encourages clients to be  
>> conservative
>> when opening multiple connections.
>> """
> It really seems like this is ripe for a Connection: max=# tag  
> recommendation.
> Wherein the application can recommend a number of parallel  
> connections that
> 1) they support and 2) provide optimal user/application experience.   
> But this
> would be out of scope of 2616bis :)

Mark Nottingham     http://www.mnot.net/
Received on Monday, 19 October 2009 22:24:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC