The Proxy-Connection: header is a mistake in how some web browsers use HTTP.

You've come to this page because you've asked questions similar to the following:

What is the Proxy-Connection: header in HTTP? It isn't documented in any standards document.

This is the Frequently Given Answer to such questions.

The Proxy-Connection: header is a mistake in how some web browsers use HTTP. Its name is the result of a false analogy. It is not a standard part of the protocol. There is a different standard protocol mechanism for doing what it does. And its existence imposes a requirement upon HTTP servers such that no proxy HTTP server can be standards-conforming in practice.

The mechanism that the Proxy-Connection: header is intended to provide is a mechanism for negotiating the persistence of a single connection between a given client and a given proxy server. By default, an HTTP version 1.0 connection is non-persistent and an HTTP version 1.1 connection is persistent. The Proxy-Connection: header is intended as a mechanism for negotiating the non-default behaviour:

HTTP already has a mechanism for this purpose. It is the Connection: header, documented in RFC 2616 § 14.10. Part of the reason that the Proxy-Connection: header is a mistake is that there is no need for another header to do the same thing. The Connection: header provides exactly the same functionality, less the faulty part, as the Proxy-Connection: header is intended to; and, moreover, provides it for any connection between any HTTP server, content or proxy, and its clients, not just for connections specifically between proxy servers and their clients.

The existence of the Proxy-Connection: header is in part based upon a false analogy to the Authorization: (RFC 2616 § 14.8) and the Proxy-Authorization: (RFC 2616 § 14.34) headers. The former is an end-to-end header, that is passed unchanged through all proxy servers and used by the web browser to communicate with the content server; whereas the latter is a single-hop header, that is not passed through by proxy servers and that is used by a web browser, or by (the back-end of) a proxy server, to communicate with the proxy server that is immediately downstream in the chain of proxy servers leading to the content server. The false analogy is that therefore the Connection: header is an end-to-end header used for talking to content servers, and the Proxy-Connection: is a single-hop header used for talking to the immediately downstream proxy server.

In fact, as RFC 2616 § 14.10 states, the Connection: header is a single-hop header. It is not, after all, meaningful to have an end-to-end persistence negotiation mechanism. Connection persistence is, by its very nature, a single-hop concept.

Unfortunately, existing web browsers employ the Proxy-Connection: header, and, moreover, they choose between it and the Connection: header depending from whether they believe they are talking to a proxy server or to a content server. Netscape Navigator did this originally. In Internet Explorer, Microsoft apparently decided simply to copy what Navigator did. Mozilla does it, too. (And the comment in the Navigator/Mozilla source about what RFC 2616 § 19.6.2 mandates for HTTP 1.1 clients is wrong, to boot. It mandates no such thing.)

The consequence of this is that, despite the fact that it is contrary to RFC 2616 § 4.5, proxy servers must treat the Proxy-Connection: header not as an entity header, but as a general header. In HTTP 1.1 requests, they must treat it as they would treat the Connection: header; and in HTTP 1.0 and earlier requests, they must ignore it and throw it away. Neither is how they would treat an entity header.

© Copyright 2007 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.