W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: NEW ISSUE(S): Retrying Requests

From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
Date: Fri, 7 Mar 2008 00:29:39 +0100
To: Jamie Lokier <jamie@shareable.org>
Cc: Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Message-ID: <20080306232939.GI1599@polar.elf12.net>

On Thu, Mar 06, 2008 at 08:22:13PM +0000, Jamie Lokier wrote:
> 
> Robert Siemer wrote:
> > On Thu, Mar 06, 2008 at 12:33:45AM +0000, Jamie Lokier wrote:
> > 
> > > I'm still puzzled as to when a client should reuse a persistent
> > > connection for requests that (it knows) shouldn't be retried.
> > > 
> > > Since all servers close a persistent connection an unspecified time
> > > after the first request, and that's perfectly healthy (all servers
> > > must do it), ...
> > 
> > Why must all servers do that?
> 
> Two reasons:
> 
>    1. Because idle TCP/IP sockets get into a stuck state, if the other
>       end disappears off the net.  Especially on internet facing
>       servers, these tend to accumulate without bound (older servers
>       had to be rebooted from time to time because of this).


Newer servers have TCP keepalive.


>       Servers will accumulate these until they run out of ports or
>       memory, if they don't have some way to drop old, idle connections.


The server runs out of port 80? What ports are you talking about?

Apart from that you just switched from "persistent connections" to "old, 
idle connections". TCP connections don't grow old. Servers don't need to 
close connections in use - be it after the 100th or 100000th request or 
be it after a "long" time.


>    1. To defend against too many clients keeping connections open for
>       an arbitrarily long time, whether maliciously or too popular.


You give your second reason the same number (1.), because it is actually 
the same? ;-)   Apart from memory consumption is there anything else to 
defend?



Robert
Received on Thursday, 6 March 2008 23:29:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT