RE: Connection: close (was: Re: Msg header)

Another reason why the UA should pay more attention to the "close"
value of the Connection header than the "keep-alive" value is that if
the client keeps the persitent connection open there will be a delay
whilst the server waits for timeout before bringing the connection
down.

Even if the server *does* mean to keep the connection alive it can
always resend responses.

But if the UA keeps the connection open the user is left waiting for
the timeout period. That's not very user friendly... it was also what
prompted Jim to ask the question in the first place (so in his
situation it would obviously have been the "correct" thing to do).


One more reason for closing the connection in Jims case is that
"Connection: keep-alive" is not a defined part of the HTTP/1.1 spec.
The token keep-alive has no meaning. See section 14.10 of RFC2616.


And the last reason I can think of is that the "Connection:
keep-alive" header:token value is the system used by some HTTP/1.0
servers which presumes that the connection will be closed unless
otherwise specified.

It could be that what is being talked to by Jim is an HTTP/1.0
webserver connected to an HTTP/1.1 servlet engine (or possibly vice
versa). 

Imagine it: the servlet engine is behaving with what it understands
of it's protocol - it sets the response to HTTP/1.1 and puts in the
"Connection: close" header because it no longer needs the connection.
But then the slightly stupid webserver takes over and adds it's own
concept of the "Connection" header - thus confusion.

Remember that 1.0 relied upon the client to close the connection if
it wished, essentially saying this:
  If there is a UA at the end of this connection who 
  understands this persistence protocol and wishes 
  the connection to remain open it will hold it open, 
  otherwise it'll get closed down

Therefore, thinking pragmatically,  HTTP/1.1 UAs (and proxies on the
server side) should always prioritize a "close" higher than anything
else.


Nic

Received on Saturday, 2 September 2000 13:57:52 UTC