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

On Thu, 2 Nov 2000, James Lacey wrote:

> > > 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 it
> > > 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.
> >
> > Huh?  That would be a webserver with some very... odd ideas.
> >
> > If you are talking about "Connection: Keep-Alive" then you appear to be
> > talking about HTTP/1.0, in which there is no chunked encoding so
> > unless the server puts a content-length on its dynamic content
> > (which is perfectly possible for it to do, but many don't for
> > reasons that are also perfectly legitimate) then there is no way
> > to use a persistent connection since in that case the only
> > end-of-reponse marker you have is the close of connection.
> As a concrete example the iPlanet Enterprise v4.1 server always
> closes the connection after responding to a POST request or
> anytime that dynamic content is generated (possibly because
> the response does not have a Content-Length: header field
> and the response is not chunked).
> I have verified this and it is clearly documented in their
> literature.

You are missing the point; it doesn't do it out of some odd desire
to "share" since a client has "had it's fill of dynamic content
for now", like you suggested it does.

Received on Thursday, 2 November 2000 10:22:46 UTC