Re: [squid-users] Persistent Connections

ons 2006-09-20 klockan 09:52 -0700 skrev Mark Nottingham:
> RFC2616 refers to RFC2068 for HTTP/1.0-style persistent connections,
> which is the most normative source we have for this.
> http://rfc.net/rfc2068.html#s19.7.1

which doesn't define persistent proxy connections at all, other than a
"MUST NOT" which doesn't make anyone much happier.. (and which nobody
follows anyway).

> The way that that's written leads me to believe that a HTTP/1.1
> client can send a request to a HTTP/1.0 server and expect the
> resulting connection to be persistent, as long as it has a Content-
> Length.

Not really. From that same section:

   An HTTP/1.0 server would then respond with the Keep-Alive connection
   token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
   persistent connection.

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.

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

and 19.6.2 says:

   response. The result is that HTTP/1.0 clients must be prevented from
   using Keep-Alive when talking to proxies.

The only document I know of which defines persistent HTTP/1.0 proxy
connections is the original Netscape document, defining the
Proxy-Connection header and why it is needed.. The validity of the
reasoning behind Proxy-Connection can be debated as the solution isn't
safe at all (fails in hierarchies), but at least it solved the client
migration path while there existed dumb HTTP/1.0 proxies without
persistent connections.

> 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). For proxy connections it's
signaled using Proxy-Connection: keep-alive, for origin server
connections using Connection: keep-alive, the difference is there to
sort of work around old HTTP/1.0 proxies not knowing about keep-alive. A
HTTP server/proxy can not assume a HTTP/1.0 client knows about HTTP/1.1
so keep-alive must be signaled in the same manner in the response as
well, and similarly it cannot be blindly assumed a HTTP/1.1 client knows
about HTTP/1.0 persistent connections. The only specifications available
actually defining persistent proxy connections (the Netscape
specifications) defines the Proxy-Connection header for the purpose.
This was not taken up in the official specifications as it can not be
guaranteed the negotiation works in all configurations.

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?

Regards
Henrik