Re: #300: Define non-final responses

On Mon, Jul 18, 2011 at 05:46:20PM +1200, Adrien de Croy wrote:
> 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.

It depends, if the proxy understands the Upgrade header and what it
means, it's allowed to emit it on the other side. For instance, the
proxy might know that the header holds a list of protocols that it
can become transparent to because it's switching to a tunnel once
it sees 101+Upgrade. In my opinion, it does not necessarily have to
understand all of the header's values.

> 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.

Indeed, if it is as you're saying, it will never be usable that way.

> 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?

No, I introduced the suggestion of using CONNECT when I joined the WG 2
years ago when I was a bit shoked to see an HTTP-incompatible handshake
(some bytes had to be sent from the client to the server for the Upgrade
to be possible). But along the discussions, it appeared that CONNECT was
not a good idea with origin servers, because it was never meant for that
use, the destination address would not make much sense either, and it
would present a risk of misbehaviour when the request would pass through
intermediaries : since by definition CONNECT is for proxies, intermediaries
in the chain would have no way to know if the request has to be processed
as a proxy or as a gateway. So we dropped that idea.

Regards,
Willy

Received on Monday, 18 July 2011 06:02:08 UTC