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

Marc Slemko wrote:

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

OK. OK. I get your point.

It may not be out of some odd desire to "share".

But it is certainly based on the idea that many
clients need to be serviced with relatively few
connections.

Received on Thursday, 2 November 2000 11:24:56 UTC