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:

• A client using HTTP 1.0 to talk to a proxy server can send Proxy-Connection: keep-alive in a request message to request that the server treat the connection as a persistent connection, if it is capable of doing so.

  Note that this is faulty protocol design that is prone to error, as RFC 2616 § 19.6.2 explains. The client cannot know that a proxy server that only understands HTTP 1.0 will not simply pass the header through, and thus cannot know that the header will be processed by the immediately downstream server (where it needs to be processed in order for connection negotiation to work).

• A proxy server using HTTP 1.0 to talk to a client can send Proxy-Connection: keep-alive in a response message to inform the client that it will honour a request to treat the connection as a persistent connection.

  As RFC 2616 § 19.6.2 explains, a proxy server cannot reliably do this, because it cannot reliably know that the header came from the client, and not from somewhere upstream of it.

• A client using HTTP 1.1 to talk to a proxy server can send Proxy-Connection: close in a request message to inform the server that it will be closing the connection after this transaction.

• A proxy server using HTTP 1.1 to talk to a client can send Proxy-Connection: close in a response message to inform the client that it will be closing the connection after this transaction.

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.