W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 2000

Re: Of HTTP/1.1 persistent connections and TCP Keepalive timers

From: James Lacey <James.Lacey@Motorola.com>
Date: Thu, 02 Nov 2000 11:11:16 -0600
Message-ID: <3A01A034.88DF3EF9@Motorola.com>
To: http-wg <http-wg@hplb.hpl.hp.com>
Jeff.Hodges@kingsmountain.com wrote:

> Thanks for all the info about how web servers are typically implemented. My
> apologies tho, I didn't really make my questions clear. What I'm really
> interested in is how *browsers* are typically implemented, because, say, I'm
> going to write my own HTTP/1.1-speaking gizmo for a very application-specific
> purpose, and I have reasons to want it (the server side) to treat
> client-initiated connections as persistent.

The server-side will do whatever it wants no matter what you do on
the client side.

Believe me. I have been down this road.

If you are assuming that just because the HTTP protocol talks about
persistent connections that you will be able to connect to a typical
web server and have the connection stay up as long as you do things
on the client side 'just right' you are mistaken.

As I said before web servers actively look for reasons to close connections.
There is _nothing_ that you can do on the client side to prevent this.
Send Connection: Keep-Alive all you want. It will not keep the web
server from closing the connection whenever it darn well feels like it.

> So this causes me to be curious about how BROWSERS will typically behave in
> this context.
> Assuming one writes one's own HTTP/1.1-speaking gizmo (according to RFC2616),
> then I have these questions...
> 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 TCP/IP keep alive!

Almost no one uses TCP/IP keep alive mechanisms.

As John Stracke pointed out the use of TCP/IP keep
alive actually makes your application less reliable
and more likely to close an idle connection for no

> Q2. What typical assumptions are made on the BROWSERS' parts about an
> established connection to a HTTP/1.1-speaking server in the absence of user
> actions? If a browser opened a HTTP/1.1 connection and such a server is
> behaving as-specified by RFC2616, then it is up to the browser to close the
> connection. What do browsers typically do?

Typically, browsers do not close the connection.

For example, suppose the  server sends back an HTTP response to the client
that does not have a Content-Length: header field and that it is not

Then the only way the client knows that it has read the
entire response off of the pipe is when the server closes the connection.
When the server closes the connection the client will receive a
zero-byte read which is socket layer's indication that the pipe
is broken.

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

My guess is that until the server closes the connection.

Which by the way, will be sooner than later.

> Q3. Are the popular BROWSERS typically speaking HTTP/1.1, or HTTP/1.0? I
> didn't
> notice any config parameters that might have something to do with setting the
> default.

I've done some snoops on browsers that are GETting HTML pages with
lots of embedded links that are in the same realm as the original HTML

Despite this obvious opportunity to take advantage of persistent connections
the browser opens  a connection for each subsequent GET.

This is true even though the browser is advertising that it supports HTTP/1.1
Most browsers seem to be supporting receiveing of chunked dynamic content
rather than persistent connections ...

> thanks again,
> JeffH
Received on Thursday, 2 November 2000 17:12:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:36 UTC