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

From: [email-masked]
Date: Thu, 02 Nov 2000 08:46:04 -0800

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.

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?

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?

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?

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.

thanks again,

JeffH

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 2 Nov 2000 12:06:52 -0500

--
Scott Lawrence         Architect             <[email-masked]>
Virata             http://www.virata.com/         http://emweb.com/

> it is actually used by the browser), or do they typically

They don't leave connections open and idle long enough for this to be
relevant.  Browsers typically close idle connections in one or two
minutes, even if the server does not.

> I looked through the documented configuration parameters

Communicator doesn't do 1.1 yet.

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.

The default for direct connections in IE is 1.1; I believe that Opera
also uses 1.1 by default now.

---

From: James Lacey <[email-masked]>
Date: Thu, 02 Nov 2000 11:11:16 -0600

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

> it is actually used by the browser), or do they typically set this value to

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
reason!

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

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.

> sit in the ESTABLISHED state?

My guess is that until the server closes the connection.

Which by the way, will be sooner than later.

> notice any config parameters that might have something to do with setting the

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

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