5.1 Implications of Hop By Hop Upgrade
If an origin server receives an Upgrade header from a proxy and
responds with a 101 Switching Protocols response, it is changing the
protocol only on the connection between the proxy and itself.
Similarly, a proxy might return a 101 response to its client to
change the protocol on that connection independently of the protocols
it is using to communicate toward the origin server.
These scenarios also complicate diagnosis of a 426 response. Since
Upgrade is a hop-by-hop header, a proxy that does not recognize 426
might remove the accompanying Upgrade header and prevent the client
from determining the required protocol switch. If a client receives
a 426 status without an accompanying Upgrade header, it will need to
request an end to end tunnel connection as described in Section 5.2
and repeat the request in order to obtain the required upgrade
information.
This hop-by-hop definition of Upgrade was a deliberate choice. It
allows for incremental deployment on either side of proxies, and for
optimized protocols between cascaded proxies without the knowledge of
the parties that are not a part of the change.
5.2 Requesting a Tunnel with CONNECT
A CONNECT method requests that a proxy establish a tunnel connection
on its behalf. The Request-URI portion of the Request-Line is always
an 'authority' as defined by URI Generic Syntax [2], which is to say
the host name and port number destination of the requested connection
separated by a colon:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
RFC 2817 HTTP Upgrade to TLS May 2000
Other HTTP mechanisms can be used normally with the CONNECT method --
except end-to-end protocol Upgrade requests, of course, since the
tunnel must be established first.
For example, proxy authentication might be used to establish the
authority to create a tunnel:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
Like any other pipelined HTTP/1.1 request, data to be tunneled may be
sent immediately after the blank line. The usual caveats also apply:
data may be discarded if the eventual response is negative, and the
connection may be reset with no response if more than one TCP segment
is outstanding.
5.3 Establishing a Tunnel with CONNECT
Any successful (2xx) response to a CONNECT request indicates that the
proxy has established a connection to the requested host and port,
and has switched to tunneling the current connection to that server
connection.
It may be the case that the proxy itself can only reach the requested
origin server through another proxy. In this case, the first proxy
SHOULD make a CONNECT request of that next proxy, requesting a tunnel
to the authority. A proxy MUST NOT respond with any 2xx status code
unless it has either a direct or tunnel connection established to the
authority.
An origin server which receives a CONNECT request for itself MAY
respond with a 2xx status code to indicate that a connection is
established.
If at any point either one of the peers gets disconnected, any
outstanding data that came from that peer will be passed to the other
one, and after that also the other connection will be terminated by
the proxy. If there is outstanding data to that peer undelivered,
that data will be discarded.
6. Rationale for the use of a 4xx (client error) Status Code
Reliable, interoperable negotiation of Upgrade features requires an
unambiguous failure signal. The 426 Upgrade Required status code
allows a server to definitively state the precise protocol extensions
a given resource must be served with.
RFC 2817 HTTP Upgrade to TLS May 2000
It might at first appear that the response should have been some form
of redirection (a 3xx code), by analogy to an old-style redirection
=4= |