W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Issue 240: Migrate Upgrade details from RFC2817

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 28 Oct 2010 15:55:39 +0200
Message-ID: <4CC980DB.8060508@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
Hi,

quoting the issue:

"RFC2817 contains advice and details about how Upgrade works in HTTP; 
e.g., the 426 status code, and the upgrade token registry."

We already took over the upgrade token registry in draft -07, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/172>.

This leaves us with:

1) Extending the definition of "Upgrade", and

2) Defining 426.

With respect to 1, let's have a look at 
<http://greenbytes.de/tech/webdav/rfc2817.html#rfc.section.4.1>:

> 4.1 Optional Advertisement
>
> As specified in HTTP/1.1 [1], the server MAY include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of the protocols listed.

 From my reading of 2616 and P1, this is partly wishful thinking. 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#rfc.section.9.8> 
says:

> 9.8 Upgrade
>
> The "Upgrade" general-header field allows the client to specify what additional communication protocols it would like to use, if the server chooses to switch protocols. Additionally, the server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched to.

...but it doesn't really say what Upgrade means in responses other than 
101. I assume we are ok with adopting the RFC 2817 interpretation?

With respect to 2):

<http://greenbytes.de/tech/webdav/rfc2817.html#rfc.section.4.2> says:

"4.2 Mandatory Advertisement

A server MAY indicate that a client request can not be completed without 
TLS using the "426 Upgrade Required" status code, which MUST include an 
an Upgrade header field specifying the token of the required TLS version.

     HTTP/1.1 426 Upgrade Required
     Upgrade: TLS/1.0, HTTP/1.1
     Connection: Upgrade

The server SHOULD include a message body in the 426 response which 
indicates in human readable form the reason for the error and describes 
any alternative courses which may be available to the user."

This would need to be a bit rephrased to remove the TLS stuff.

Here are the proposed changes:

Part 1, Upgrade:

"The "Upgrade" general-header field allows the client to specify what 
additional communication protocols it would like to use, if the server 
chooses to switch protocols. Additionally, the server MUST use the 
Upgrade header field within a 101 (Switching Protocols) response to 
indicate which protocol(s) are being switched to."

-->

"The "Upgrade" general-header field allows the client to specify what 
additional communication protocols it would like to use, if the server 
chooses to switch protocols.

Servers MAY include the "Upgrade" header field in any response other 
than 101 (Switching Protocols) or 426 (Upgrade Required) to indicate 
that they are willing to upgrade to one of the specified protocols.

Servers MUST include it in 101 (Switching Protocols) responses to 
indicate which protocol(s) are being switched to, and MUST include it in 
426 (Upgrade Required) responses to indicate acceptable protocols to 
upgrade to."

Part 2, add Status 426 as:

"8.4.19 426 Upgrade Required

The request can not be completed without a prior protocol upgrade. This 
response MUST include an Upgrade header field specifying the tokens of 
the required protocol.

Example:

     HTTP/1.1 426 Upgrade Required
     Upgrade: HTTP/2.0
     Connection: Upgrade

The server SHOULD include a message body in the 426 response which 
indicates in human readable form the reason for the error and describes 
any alternative courses which may be available to the user."

Question: what exactly would it mean if the Upgrade header in a 426 
response contains multiple tokens? Are all of them required, or can the 
client pick one?

Best regards, Julian
Received on Thursday, 28 October 2010 13:56:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:31 GMT