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: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Date: Thu, 2 Nov 2000 16:24:23 +0100
To: <Jeff.Hodges@KingsMountain.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Message-ID: <000801c044e0$fbba7d80$01ff1fac@Thuis.local>
> -----Original Message-----
> From: hodges@breakaway.Stanford.EDU
> [mailto:hodges@breakaway.Stanford.EDU]On Behalf Of
> Jeff.Hodges@KingsMountain.com
> Sent: Thursday, 02 November 2000 8:44
> To: http-wg@hplb.hpl.hp.com
> Cc: Jeff.Hodges@KingsMountain.com
> Subject: Of HTTP/1.1 persistent connections and TCP Keepalive timers
> 
> 
> I'm curious about how HTTP/1.1 [RFC2616] persistent 
> connections typically work 
> with respect to the typical browsers out in the wild today 
> (Netscape & 
> Microsoft being the two I'm particularly interested in). If I 
> cause a browser 
> to send a GET request for a given URL (using HTTP/1.1) to a 
> server, and the 
> server doesn't encounter any errors in processing it and 
> responding, and then 
> I (say) don't touch the browser for hours, what *typically* 
> happens to the 
> established HTTP/1.1 (-over-TCP) connection?
> 

<<<SNIP>>>

> 
> Some questions (again, in the case of HTTP/1.1 persistent 
> connections):
> 
> 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?

HTTP/1.1 does not rely on the TCP timeout/keepalive. A HTTP/1.1 connected is alive only if the lower-layer connection is in the CONNECTED state.
> 
> 
> Q2. What typical assumptions are made on the browsers' parts about an 
> established connection to a web site in the absence of user 
> actions? If a
> browser opened a HTTP/1.1 connection and the server is 
> behaving as-specified 
> by RFC2616, then it is up to the browser to close the 
> connection. What do 
> browsers typically do? I looked through the documented configuration 
> parameters for Netscape Communicator..
> 
>   
> http://docs.iplanet.com/docs/manuals/communicator/newprefs/new
> prefn.html
> 
> ..and could not find a timeout setting that's applicable for this particular 
> case. How long will browsers, that are speaking HTTP/1.1, let this connection 
> sit in the ESTABLISHED state?

The browser can leave the connection open for an infinite ammount of time (if not restricted by lower-level protocols, like TCP).

However, idle time-outs when the connection is CONNECTED are, in the real world, handled by the server instead of the client. This is because the server is not interrested in HTTP connections that are idle for an infinite ammount of time and just consuming bandwidth (the lower-level connection must be maintained)...

In the real world, the server does close the connection (when it's idle) without an explicit message that the connection is going to be closed. The server also cannot do this on HTTP level.



> Q3. Are the popular browsers typically using HTTP/1.1, or HTTP/1.0? I didn't 
> notice any config parameters that might have something to do with setting the 
> default.

HTTP/1.1, this version indicates the browser is capable of handling features that are not supported in HTTP/1.0 (such as HTTP keepalive).

MSIE (for Windows) supports HTTP/1.1, but also HTTP/1.0 (default for proxy connections). Here the settings can be changed...

The version is also always send with a HTTP request or response (to indicate the browser/server capacties).

> 
> thanks,
> 
> JeffH
> 
> 


Hope to inform you. Maybe comments from the WG?


- Joris
Received on Thursday, 2 November 2000 15:26:16 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:40 EDT