one comment I'd like to make.
When I first read the definition for Upgrade in RFC2616, I switched
off as soon as I saw the word "additional communications protocols"
which didn't make any sense to me.
IMO it should read "alternative communications protocols", since if
the header is acted on, the protocol will be changed to rather than
Also, this is a classic case of why HTTP/1.1 intermediaries MUST
strip headers matching tokens in the Connection header. It makes me
wonder what will happen if an HTTP/1.0 proxy receives one of these
and forwards it. Is there a requirement on servers to ignore
upgrade on an HTTP/1.0 request?
I also wonder what an HTTP/2.0 proxy should send upstream when
receiving Upgrade: HTTP/2.0 in an HTTP/1.1 request.
The example is also slightly confusing.
It refers to "Upgrade: HTTP/2.0"
however the registered key-word with the IANA is only "HTTP", and
doesn't include any version number.
I don't see any discussion for the production of "product" in the
BNF for Upgrade, which would need to include version number (as
opposed to it being optional in the product production in S 3.8) in
order for this example to be correct according to the current IANA
registry, or would we need to register a separate value with the
IANA of "HTTP/2.0" (which is in keeping with the way TLS/1.0 is
registered)? On that note, it may be prudent to consider versioning
in this aspect for WebSocket. At the very least there is
inconsistency about how the 3 tokens are currently registered, with
TLS including version and the others not.
Without version number, registering the bare "HTTP" token is
probably of little use. Especially since if the version defines
aspects such as new (incompatible) framing etc, then the version is
a key part of the actual protocol being referred to and can't really
be omitted. In that sense, if a server received
then the only sensible thing to do is ignore it.
It makes me wonder whether the BNF for Upgrade should have referred
to product or some other production requiring version, and being
designed to be the name of a protocol (non-optional version) rather
than the name of a product. c.f.
product = token ["/" product-version]
product-version = token
On 31/10/2010 6:05 a.m., Julian Reschke wrote:
I have made the following changes in
P1: rephrase definition of Upgrade header field so that it states
the semantics for status codes != 101:
-- snip --
The "Upgrade" general-header field allows the client to specify
additional communication protocols it would like to use, if the
server chooses to switch protocols. Servers can use it to
what protocols they are willing to switch to.
Upgrade = "Upgrade" ":" OWS Upgrade-v
Upgrade-v = 1#product
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple
for transition from HTTP/1.1 to some other, incompatible
It does so by allowing the client to advertise its desire to
another protocol, such as a later version of HTTP with a higher
version number, even though the current request has been made
HTTP/1.1. This eases the difficult transition between
protocols by allowing the client to initiate a request in the
commonly supported protocol while indicating to the server that
would like to use a "better" protocol if available (where
determined by the server, possibly according to the nature of
method and/or resource being requested).
The Upgrade header field only applies to switching
protocols upon the existing transport-layer connection.
cannot be used to insist on a protocol change; its acceptance
by the server is optional. The capabilities and nature of the
application-layer communication after the protocol change is
dependent upon the new protocol chosen, although the first
after changing the protocol MUST be a response to the initial
request containing the Upgrade header field.
The Upgrade header field only applies to the immediate
Therefore, the upgrade keyword MUST be supplied within a
header field (Section 9.1) whenever Upgrade is present in an
The Upgrade header field cannot be used to indicate a switch to
protocol on a different connection. For that purpose, it is
appropriate to use a 3xx redirection response (Section 8.3 of
Servers MUST include the "Upgrade" header field in 101
Protocols) responses to indicate which protocol(s) are being
to, and MUST include it in 426 (Upgrade Required) responses to
indicate acceptable protocols to upgrade to. Servers MAY
in any other response to indicate that they are willing to
one of the specified protocols.
This specification only defines the protocol name "HTTP" for
the family of Hypertext Transfer Protocols, as defined by the
version rules of Section 2.5 and future updates to this
specification. Additional tokens can be registered with IANA
the registration procedure defined below.
-- snip --
In Part 2, add definition of status code 426:
-- snip --
8.4.19. 426 Upgrade Required
The request can not be completed without a prior protocol
This response MUST include an Upgrade header field (Section 9.8
[Part1]) specifying the required protocols.
HTTP/1.1 426 Upgrade Required
The server SHOULD include a message body in the 426 response
indicates in human readable form the reason for the error and
describes any alternative courses which may be available to the
-- snip --
I believe we are done with ticket 240, and should treat all
remaining issues as separate bugs...
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com