Re: #158: Proxy-Connection and Keep-alive

OK, one more go at this.

Willy, you said:

> I'm not asking to emit the Keep-alive header, rather just to suggest
> clients to continue to emit "Connection: keep-alive" when they suspect
> the proxy could be 1.0, as they're doing right now.

Understand that using Connection: keep-alive with 1.0 proxies is *precisely* the cause of the interoperability problems that led to the design of persistent connections in 1.1; because 1.0 proxies aren't required to remove the Connection: header (or what it refers to), this can result in hanging connections. 

While *most* proxies have upgraded to implement this, you cannot count on it; they aren't required to implement it in 1.0, and IME there are still some that don't. I know that the proxies that you (Willy and Amos) are implementing now don't have this problem currently, but we're concerned with the entire installed base of proxies, not just current products.

So, suggesting that they do it is too strong; there are legitimate reasons to be concerned about interoperability in this use case, and we're all about the interoperability.

See below for another go at a proposal. Personally, I think this is as far as we can go; others may feel differently (in either direction), and are encouraged to say so (I'd like to get this one nailed down).

Replace p1 A.1.2 with:

> In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections described in Section 19.7.1 of [RFC2068].
> Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand Connection, it will erroneously forward that header to the next inbound server, which would result in a hung connection.
> One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed above.
> As a result, clients are encouraged not to send the Proxy-Connection header in any requests.
> Clients are also encouraged to consider the use of Connection: keep-alive in requests carefully; while they can enable persistent connections with HTTP/1.0 servers, clients using them need will need to monitor the connection for "hung" requests (which indicate that the client ought stop sending the header), and this mechanism ought not be used by clients at all when a proxy is being used.


Mark Nottingham

Received on Friday, 9 December 2011 05:27:52 UTC