Here a further interesting message on HTTP.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
-----Original Message-----
From: Joris Dobbelsteen [mailto:joris.dobbelsteen at mail.com]
Sent: Thursday, November 02, 2000 7:24 AM
To: Jeff.Hodges at KingsMountain.com
Cc: WWW WG (E-mail)
Subject: RE: Of HTTP/1.1 persistent connections and TCP Keepalive timers
> -----Original Message-----
> From: hodges at breakaway.Stanford.EDU> [mailto:hodges at breakaway.Stanford.EDU]On Behalf Of
>Jeff.Hodges at KingsMountain.com> Sent: Thursday, 02 November 2000 8:44
> To: http-wg at hplb.hpl.hp.com> Cc: Jeff.Hodges at 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