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 - 11:58:58 EST

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


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

    -----Original Message-----
    From: 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
    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



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