IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalive timers

IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalive timers

IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalive timers

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Thu Nov 2 11:58:58 EST 2000


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 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: Jeff.Hodges at kingsmountain.com
[mailto:Jeff.Hodges at kingsmountain.com]
Sent: Wednesday, November 01, 2000 11:44 PM
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
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
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
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
changed. They normally want it much lower, on the order of minutes. As we
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,
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:


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 
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..


..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
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



More information about the Ipp mailing list