UPGRADE: Wording

I looked through the mailing list archives and found no reference to
the upgrade header other than Larry's remark whether it should be
included or not.

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.

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.

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

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.

However, as a result of the tight time constraint on the HTTP draft, I
think it is more important to provide a working solution than a
complete technical solution. As the upgrade header provides an
important transition path within HTTP itself to change the protocol
version, the best solution for now is to keep the upgrade header as it
is but with a comment on the limitations above and then work on a
better solution for the next HTTP version. I have therefore added the comments 
at the end (marked with change bars)

9.1 Informational 1xx

This class of status code indicates a provisional response, consisting
only of the Status-Line and optional headers, and is terminated by an
empty line. Since HTTP/1.0 did not define any 1xx status codes,
servers should not send a 1xx response to an HTTP/1.0 client except
under experimental conditions.

100 Continue

The client may continue with its request. This interim response is
used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The client
should continue by sending the remainder of the request or, if the
request has already been completed, ignore this response. The server
must send a final response after the request has been completed.

101 Switching Protocols

The server understands and is willing to comply with the client's
request, via the Upgrade message header field (Section 10.41), for a
change in the application protocol being used on this connection. The
server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which terminates
the 101 response.

The protocol should only be switched when it is advantageous to do
so. For example, switching to a newer version of HTTP is advantageous
over older versions, and switching to a real-time, synchronous
protocol may be advantageous when delivering resources that use such
features.

------

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.


-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Monday, 1 April 1996 08:18:25 UTC