All,
This message just appeared on the HTTP WG list. You may be interested to
learn more about this subject or to take part in the HTTP WG discussion.
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@cp10.es.xerox.com
-----Original Message-----
From: Jeff.Hodges@kingsmountain.com
[mailto:Jeff.Hodges@kingsmountain.com]
Sent: Wednesday, November 01, 2000 11:44 PM
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?
I note that RFC2616 says (in part)..
:
8 Connections
8.1 Persistent Connections
:
HTTP implementations SHOULD implement persistent connections.
:
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client
SHOULD assume that the server will maintain a persistent connection,
even after error responses from the server.
:
As it is written, this effectively puts the responsibility for closing the
HTTP/1.1-cum-TCP connection on the client.
In nosing around on this subject, I note that in [W.R.Stevens, TCP/IP
Illustrated Vol 1, http://www.dqc.org/~chris/tcpip_ill/], in chapter 23
Stevens says that..
1. "Keepalives are not part of the TCP specification. ... Nevertheless, many
implementations provide the keep-alive timer."
2. "If there is no activity on a given connection for 2 hours, the server
sends a probe segment to the client. ... A perpetual question by people
discovering the keepalive option is whether the 2-hour idle time value can
be
changed. They normally want it much lower, on the order of minutes. As we
show
in Appendix E, the value can usually be changed, but in all the systems
described in this appendix, the keepalive interval is a system-wide value,
so
changing it affects all users of the option. "
..and in appendix E he shows kernel configuration parameters for several
Unix-based TCP implementations, most all of which have a default 2-hour
timeout *before* a keepalive packet will be sent.
I also note that Microsoft shows a default value of 2 hour idletime for the
keepalive timer in this doc:
http://www.microsoft.com/technet/winnt/reskit/sur_tcp2.asp
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?
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/newprefn.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?
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.
thanks,
JeffH
This archive was generated by hypermail 2b29 : Thu Nov 02 2000 - 12:24:19 EST