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

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

Received on Thursday, 2 November 2000 08:53:31 UTC