W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: #250 / #251 (connect bodies)

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 28 Oct 2010 10:36:41 -0700
Message-ID: <AANLkTinMabP0yQyvTFjRyfhdr4q=V1auYDC2uompMJmC@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
This sounds like a valuable discussion to have in the HyBi working
group.  I'm not sure we've got all the right folks on this mailing
list to respond to your feedback.

Adam


On Thu, Oct 28, 2010 at 2:00 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> 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 17:38:26 GMT

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