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

Re: #250 / #251 (connect bodies)

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 29 Oct 2010 10:09:44 +1100
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>
Message-Id: <163B053C-7C6E-460B-AF1C-6F00AA8F7064@mnot.net>
To: Adam Barth <w3c@adambarth.com>
It (i.e., not using port 80) has already been raised many times, doubtless it'll be raised again.

Regards,


On 29/10/2010, at 4:36 AM, Adam Barth wrote:

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

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 28 October 2010 23:10:19 GMT

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