- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 18 Jul 2011 17:46:20 +1200
- 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 non-starter. 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 originally? 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