Re: UPGRADE: Wording

> I think that Roy's wording is a good start, but it has two important
> limitations that should be resolved:
> 
> 1) It allows for switching protocols on the _same_ connection only. I
> think it is important that the header allows for upgrade on a
> different connection in order to provide sufficient support for having
> HTTP being a control connection for real time protocols, for example.

I don't.  If such a thing is desirable then it can already be implemented
via a redirect to a different URL.  However, I don't know of any real
time (or other) protocol for which it makes sense to use HTTP as the
control.  In any case, this is not a problem which Upgrade was intended
to solve -- it only handles the case of replacement of the current
application protocol with something else on the same connection.
Furthermore, the new protocol (post-Upgrade) may indeed be capable
of spawning new connections (or multiplexing within the existing
connection).

> 2) The naming of the protocol may not be sufficiently detailed as it
> does not allow for composite names and versions built together in a
> protocol stack.

It provides for a list of protocol names that are accepted by the client
for the purpose of an upgraded connection.  Composite names and protocol
stacks do not have an affect on the protocol name (unless the name
itself is a composite, which is already supported).  There are other
things that will be supported by PEP, but even PEP will need Upgrade
in order to change from HTTP/1.x to HTTP/2.x.

> 3) The client can not require that a protocol specified in the upgrade
> header is used by the server.

Right, it doesn't -- that is not the purpose of Upgrade and is the purpose
of PEP.  At the same time, PEP cannot say "change the current connection
to one using HTTP-NG" because PEP exists within HTTP.

> There are a number of possible solutions to this. First, we could use
> the notion from Simon Spero's original draft on HTTP-NG that also
> supports spawning off other connections or we could use the more
> traditional FTP solution for PORT and PASV. Second we could use a
> protocol naming scheme as used by ILU (32 bit hash) or as suggested by
> Rohit Khare in his PEP proposal.

A name is a name -- what you make of it is what you want to make of it.
There is no functional difference between a 32 bit hash and an
unrestrained token.  PEP is far too complex for an optional
application-layer protocol switch; that complexity serves its purpose,
but PEP's purpose is far more exuberant than that of Upgrade.

> 10.41 Upgrade
> 
> The Upgrade general-header allows the client to specify what
> additional communication protocols it supports and would like to use
> if the server finds it appropriate to switch protocols. The server
> must use the Upgrade header field within a 101 (switching protocols)
> response to indicate which protocol(s) are being switched.
> 
>        Upgrade        = "Upgrade" ":" 1#product
> 
> For example, 
> 
>        Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
> 
> | The purpose of the Upgrade header is to allow easier migration across 
> | protocols in order to better match the application needs with 
> | protocol capabilities. The client can not demand that a protocol 
> | specified in the upgrade header is used by the server. However, the 
> | indication given by the upgrade header field should be followed.
> |
> | The upgrade header does not allow for switching protocols on a 
> | different connection than the one in use. It also does not provide 
> | any means for switching back to the original protocol used to 
> | transmit the upgrade header in the first place.
> |
> | This specification does not define any protocol names other than 
> | "HTTP" but others can be used.

Well, no, that's not quite right.  I understand what you are trying to
say, but it is not appropriate to define a header field in terms of
what it doesn't do, and the comment about switching back is wrong
(that depends on what you change to).  How about the following instead
of the last three paragraphs above:

   The Upgrade header field is intended to provide a simple mechanism
   for transition from HTTP/1.1 to some other, incompatible protocol.
   It does so by allowing the client to advertize its desire to use 
   another protocol, such as a later version of HTTP with a higher major
   version number, even though the current request has been made using
   HTTP/1.1.  This eases the difficult transition between incompatible
   protocols by allowing the client to initiate a request in the more
   commonly supported protocol while indicating to the server that it
   would like to use a "better" protocol if available (where "better"
   is determined by the server, possibly according to the nature of the
   method and/or resource being requested).
 
   The Upgrade header field only applies to switching application-layer
   protocols upon the existing transport-layer connection.  Upgrade
   cannot be used to insist on a protocol change; its acceptance and
   use by the server is optional.  The capabilities and nature of the
   application-layer communication after the protocol change is entirely
   dependent upon the new protocol chosen, although the first action
   after changing the protocol must be a response to the initial HTTP
   request containing the Upgrade header field.

   The Upgrade header field only applies to the immediate connection.
   Therefore, the "upgrade" keyword must be supplied within a Connection
   header field (Section 10.9) whenever Upgrade is present in an
   HTTP/1.1 message.

   The Upgrade header field cannot be used to indicate a switch to a
   a protocol on a different connection.  For that purpose, it is more
   appropriate to use a 301, 302, 303, or 305 redirection response.

   This specification only defines the protocol name "HTTP" for use by
   the family of Hypertext Transfer Protocols, as defined by the HTTP
   version rules of Section 3.1 and future updates to this specification.
   Any token can be used as a protocol name; however, it will only be
   useful if both the client and server associate the name with the
   same protocol.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 1 April 1996 20:54:11 UTC