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

> -----Original Message-----
> From: jlacey@mothost.mot.com 
> [mailto:jlacey@mothost.mot.com]On Behalf Of
> James Lacey
> Sent: Thursday, 02 November 2000 20:22
> To: Marc Slemko
> Cc: http-wg
> Subject: 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.
> 
Some servers can close a connection after sending dynamic content because of security resons. (or because they are bad implementations.)

As for POST, if a server responds (except the 1xx status codes), the request must have ended. At least, this is the most logic thing for me. Also I don't know how to send a POST request without using content-length or chunked encoding and having the server knowning absolutely sure that request has ended.

- Joris

Received on Sunday, 5 November 2000 09:17:13 UTC