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.
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.
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
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.
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
Proxy-Connection: header is in part based upon a false
analogy to the
(RFC 2616 § 14.8)
(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
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
header, and, moreover, they choose between it and the
header depending from whether they believe they are talking to a proxy server
or to a content server.
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.