Re: #250 / #251 (connect bodies)

On 28/10/2010, at 6:23 PM, Willy Tarreau wrote:
> 
> I'd pose the question the other way around : how could we replace existing
> long-polling mechanisms that already work over HTTP and benefit from all
> features that have been built around HTTP, on a different port. Right now,
> virtual hosting

WebSockets on a separate port can easily identify the intended host, just as HTTP does...

> , ability to be proxied any number of times

... but as proposed, it's not, because it's so extremely brittle...

> , including through URL filters (think about schools)

... which will either block WS as a policy decision, or just block by host/port combination anyway...

> , session state management

... which can already span multiple hosts and ports...

> and server stickiness

... which would also be available on a separate port...

> are essential to web applications nowadays. If we're going to
> use a distinct port, we're losing most of these existing features, which
> will considerably lower adoption.

As you can probably tell, I don't buy it.

>>> From CONNECT, specifically, we'd like to get WebSocket-oblivious
>>> intermediaries to ignore the rest of the bytes on the socket.  CONNECT
>>> lets them know that the rest of the bytes coming from the client
>>> aren't going to be HTTP, so they shouldn't try to understand the
>>> semantics of those bytes.
>> 
>> Explicitly configured forward proxies -- as opposed to "reverse" proxies, interception (a.k.a. "transparent") proxies, L7 load balancers, firewalls and the like -- will indeed do this. Whether any of the rest will is anyone's guess, and depends upon how they're coded, whether they're ever used as a forward proxy, and how generous / clued-up the administrator is. 
> 
> Pure reverse proxies will probably not work, just as they currently don't
> work with 101 either. Firewalls and load balancers do support explicit
> proxies (those were the first users of load balancers)

They support *being* a proxy, or being a proxy behind a firewall. The question here is whether they support connections *through* them using CONNECT to another proxy. E.g., Checkpoint's URL filtering and web protection stuff, and lots of other products besides.

> and as such are
> well aware of the methods used in such environments. There's still the
> common issue of proxy-connection vs connection but there's already a bug
> open on the subject.

[...]

>> You're missing the point here -- a box that isn't expecting and explicitly handling CONNECT will also think that HTTP semantics apply beyond the end of the message. 
> 
> But do we have any chance to spot any such implementation ? That was one of
> my concern in the early days when I too proposed CONNECT, but if the
> implementation is server-side only, it generally does not support CONNECT,
> which is fine. And if it supports relaying to proxies it will support it
> with correct semantics.


No. Nothing requires an intermediary to support CONNECT, and if they don't, nothing prevents them from treating it like any other HTTP message; i.e., delimited according to HTTP, and followed by more HTTP messages. 

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 28 October 2010 09:00:54 UTC