W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 5 Dec 2011 12:01:16 +1100
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <DA488568-98EF-4D4B-9814-DD1B9004B072@mnot.net>
To: Willy Tarreau <w@1wt.eu>

On 03/12/2011, at 6:22 PM, Willy Tarreau wrote:

>  The Proxy-Connection header was completely obsoleted by the Connection
>  header. Therefore, clients must not emit it and must use the Connection
>  header instead, even with proxies running an unknown HTTP version.
> I'm insisting on this point because it's not necessarily obvious that a
> "Connection: keep-alive" header must be sent in an HTTP/1.1 request when
> the proxy's version is unknown or 1.0.


There are a number of problems with this.

* Your text effectively requires clients to send Connection: keep-alive under certain conditions. This is a new requirement that will very likely break existing implementations, and one that makes HTTP more complex.

* Furthermore, we don't define Keep-Alive, as it's not part of HTTP/1.1 (and therefore out of scope). It was previously abandoned as too problematic. Requiring use of a deprecated mechanism doesn't make sense.

* The primary motivation for doing so is compatibility with NTLM authentication, which is also not part of HTTP, and very clearly breaks HTTP. While we can attempt to improve interoperability for this broken extension, it cannot be at the cost of making HTTP itself more complex.

Clients choose whether to use persistent connections or not; it's up to them. If you want to make NTLM authentication more interoperable, I'd suggest you create a new I-D describing how to do so.

As a reminder, the current proposal text is:

> replace p1 A.1.2 with:
> Most HTTP/1.0 implementations use a separate connection for each request. However, some implement persistent connections using the Keep-Alive negotiation mechanism described in Section 19.7.1 of [RFC2068].
> In contrast, persistent connections are the default for HTTP/1.1; they do not need to be explicitly negotiated, as in HTTP/1.0. This is because there were various interoperability problems in the implementations of HTTP/1.0 persistent connections, especially when a proxy is involved.
> For example, some existing HTTP/1.0 clients might send Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies.
> However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. Some early attempts to correct this was to use the Proxy-Connection request header, but this approach was also unworkable, for similar reasons.
> Therefore, some other mechanism for indicating a persistent connection was needed -- one that is safe to use even when talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence. See Section 8.1.
> As a result, HTTP/1.1 clients ought not to send the Proxy-Connection or Keep-Alive header; at best, they will waste bytes in requests, and at worst they can cause interoperability problems. 

Mark Nottingham   http://www.mnot.net/
Received on Monday, 5 December 2011 01:01:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC