More of the same...
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: James Lacey [mailto:James.Lacey at Motorola.com]
Sent: Thursday, November 02, 2000 7:26 AM
To: http-wg
Subject: Re: Of HTTP/1.1 persistent connections and TCP Keepalive timers
Jeff.Hodges at kingsmountain.com wrote:
> 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?
The web server will close the connection due to inactivity.
You have to realize that web servers are trying to service literally
thousands of clients with only a relatively few TCP/IP connections.
If you don't use it you lose it.
Also, most web servers actively look for reasons to close a connection
to a client. For example, if the web server generates any dynamic content
for the client, then it will usually close the connection after the response
it
sent back. Regardless of whether or not the client supplied a Connection:
Keep-Alive header or not. The reasoning behind this is that if the sever
had to generate dynamic content on your behalf, then you've had your share
and its time to give some other poor slob a turn.
>>> 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.
Nope. See my comments above.
Also, you have to realize that just cuz the client sends a
Connection: Keep-Alive header it is in no way a guarantee
that the server will not close the connection after the
response is sent back.
There is a HUGE difference between the way the HTTP spec
is written and the way that web server's are actually designed
to work on the internet.
I'm not saying that the web server designers violated the
HTTP protocol. Rather they have simply done what they
have to do in order to protect their web server from
attacks, deadlocks, and starving clients.
Read further in the spec and you will see that the HTTP
spec says that unsafe methods should not be pipelined.
An unsafe method is a method that in some sense changes
the state of the server and will not necessarily generate the
same response every time it is executed.
On the internet unsafe methods are typically used to
represent a clients actions on the internet (i.e. I've just
sent a request to buy product X with my credit card
number aaaa-bbbb-cccc-dddd). Before submitting
another unsafe method I should be allowed to get
feedback about the current unsafe method and determine
if I wish to proceed with the next unsafe method or not.
So, when receiving an unsafe method (POST) most
web servers will close the connection after the response
is generated. Even if more unsafe methods have been sent
into the pipe. They are simply discarded.
>>> 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
Here I think you are confusing TCP/IP keep alive, with HTTP's
Connection header and its Keep-Alive value.
Trust me. These are two very different unrelatred things.
>>> 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?
Browsers do not use this at all I'm quite sure.
>>> 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?
Until the server closes it IMHO. The server will close the connection due
to inactivity; 30 seconds by default for iPlanet web server.
>>> 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