On 2006/09/20, at 2:14 PM, Henrik Nordstrom wrote:
But it's true that we probably could assume a HTTP/1.1 message is
persistent unless it has a connection: close tag as the close tag is
required by HTTP/1.1. But at the same time RFC 2616 8.1.2.1 says:
Clients and servers SHOULD NOT assume that a persistent
connection is
maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See section 19.6.2 for more information on backward
compatibility with HTTP/1.0 clients.
... and one could argue that it's explicitly signalled by the Content-
Length header in the response.
8.1.3 says
A proxy server MUST NOT establish a HTTP/1.1 persistent connection
with an HTTP/1.0 client (but see RFC 2068 [33] for information and
discussion of the problems with the Keep-Alive header
implemented by
many HTTP/1.0 clients).
I'm actually more interested in this in the gateway case, but point
taken.
However, since this is a spec interpretation issue, I might take it
up with the folks over at HTTP-WG.
You are welcome.
But I don't really see much value to stir up discussions around
HTTP/1.0
persistent connections, they work the ways they do and can not be
changed, only documented (was a dead end).
If you haven't seen Roy's... colourful response on HTTP-WG along
these lines, I'll forward. :)
The most significant blank spot is how HTTP/1.0 proxies knowing about
persistent connections should react to HTTP/1.1 clients not explicitly
signaling persistent connections. Here we choose take the safe path
and
assumes the client doesn't know about HTTP/1.0 persistent connections
and close the connection.
Unfortunately I have no idea where to find that Netscape document
today
after all their restructuring. Maybe in the Internet Archive?
I'll look for it.
Just thinking aloud -- the obvious solution to this is to make Squid
HTTP/1.1. Of course, that's a lot of work, but I wonder if it would
be more manageable by going 1.1 on just the client side at first,
while remaining 1.0 on the server side, to avoid chunked responses.
Yes, I realise that's pretty sick.
Cheers,
--
Mark Nottingham
mnot@xxxxxxxxxxxxx
