IPP Mail Archive: IPP> FW: Of HTTP/1.1 persistent connection

IPP Mail Archive: IPP> FW: Of HTTP/1.1 persistent connection

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

From: Manros, Carl-Uno B (cmanros@cp10.es.xerox.com)
Date: Thu Nov 02 2000 - 12:07:26 EST

  • Next message: Manros, Carl-Uno B: "IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalive timers"

    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@cp10.es.xerox.com

    -----Original Message-----
    From: James Lacey [mailto:James.Lacey@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@kingsmountain.com wrote:

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

    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
    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,
    > 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
    > 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
    > for
    > the keepalive (if such capability is provided by the TCP/IP stack, and if
    > 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
    > 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
    > case. How long will browsers, that are speaking HTTP/1.1, let this
    > 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
    > notice any config parameters that might have something to do with setting
    > default.
    > thanks,
    > JeffH

    This archive was generated by hypermail 2b29 : Thu Nov 02 2000 - 12:19:32 EST