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

Re: #300: Define non-final responses

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 18 Jul 2011 17:46:20 +1200
Message-ID: <4E23C8AC.4070806@qbik.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Ok, I re-read the sections in RFC2616.

It's pretty clearly marked as a hop-by-hop header.

This has some serious negative implications for usefulness.

If a proxy cannot pass the upgrade header through, and get out of the 
way then any new protocol to be upgraded to needs to be supported by all 
proxies in any chain.

Compared to (what appears to be common) current understanding, this 
means the problem is not one of just getting a client and server working 
which is do-able, it also means getting your proxy vendor, or any vendor 
of any proxy used by any client to also implement the protocol.  A 

This makes it basically impractical, and a show stopper for any deployment.

Maybe we need to extend CONNECT to enable it to be used against an 
origin server, and deprecate Upgrade.  This at least is fairly well 
understood by intermediaries.  AFAIK this is what Websockets was doing 

On 18/07/2011 2:51 p.m., 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.
> 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.
> ....Roy

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/
Received on Monday, 18 July 2011 05:47:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC