W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 2000

Re: Of HTTP/1.1 persistent connections and TCP Keepalive timers

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Thu, 2 Nov 2000 12:17:28 -0500 (EST)
Message-Id: <200011021717.MAA19990@aleatory.research.bell-labs.com>
To: Jeff.Hodges@kingsmountain.com
Cc: http-wg@hplb.hpl.hp.com
Jeff.Hodges@kingsmountain.com wrote:
  > Thanks for all the info about how web servers are typically implemented. My 
  > apologies tho, I didn't really make my questions clear. What I'm really  
  > interested in is how *browsers* are typically implemented, because, say, I'm 
  > going to write my own HTTP/1.1-speaking gizmo for a very application-specific 
  > purpose, and I have reasons to want it (the server side) to treat 
  > client-initiated connections as persistent.

Actually, I think most responses recognized that you were interested in
browsers.  The problem is that the browser can only express its
preference.  But the server is in command, and it can close a
connection whenever it feels it must.  That's why there were all the
comments on server behavior.  (In truth, the browser may *also* close
the connection at will, but that's a less common case.)

  > So this causes me to be curious about how BROWSERS will typically behave in 
  > this context.
  > Assuming one writes one's own HTTP/1.1-speaking gizmo (according to RFC2616), 
  > then I have these questions...

I am not a browser implementer, so my answers are speculative, but....

  > Q1. Do the popular BROWSERS typically take the platform's OS's TCP defaults 
  > for the keepalive (IF such capability is provided by the TCP/IP stack, and IF 
  > it is actually used by the browser), or do they typically set this value to
  > something in particular?

They take the OS's defaults.

  > Q2. What typical assumptions are made on the BROWSERS' parts about an 
  > established connection to a HTTP/1.1-speaking server in the absence of user 
  > actions? If a browser opened a HTTP/1.1 connection and such a server is 
  > behaving as-specified by RFC2616, then it is up to the browser to close the 
  > connection. What do browsers typically do?

Browsers probably open connections with the hope of keeping them open as
long as possible.  But as I said earlier, that doesn't mean they will stay
open.  I believe the only way the client discovers the connection has been
closed is by getting an error response when it tries to write to a (now-closed)

[Rest deleted -- I believe the questions were answered earlier.]

Dave Kristol
Received on Thursday, 2 November 2000 17:19:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:36 UTC