W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #300: Define non-final responses

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 18 Jul 2011 17:18:48 +1200
Message-ID: <4E23C238.9060208@treenet.co.nz>
To: ietf-http-wg@w3.org
On 18/07/11 14:51, Roy T. Fielding wrote:
> On Jul 17, 2011, at 6:19 PM, Adrien de Croy wrote:
>
>> For an intermediary, Upgrade + 101 needs to be handled like CONNECT + 200.
>
> No.  Look, I don't know how any of you got the impression that Upgrade
> is a request to turn into a tunnel, but that simply is not the case.

Not all middleware tunnels CONNECT. Some switch to a new protocol and 
process the internal CONNECT octets in accordance with that protocol 
spec. But only if they support and implement that protocol.

Given that implementing each new protocol takes time, and people are 
_already_ using Upgrade to switch to random other non-HTTP protocols. 
Telnet, SSH, WebSockets already happening. The alternative is to 
terminate with 4xx any request containing Upgrade: and a protocol not 
supported by that middleware.

You may like that, but the reality is a needless burden on support 
helpdesks when a blind end-to-end packet relay is already in the toolkit 
and will work.

> It cannot be implemented that way.  Please don't try.  You are not supposed
> to upgrade the connection if you don't know how to upgrade the connection.

I'm not talking about implementing Upgrade. The client and origin may be 
the only places where that is possible (as is the case for WebSockets). 
Merely transiting requests which use it.

AYJ
Received on Monday, 18 July 2011 05:19:27 GMT

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