Re: [hybi] [whatwg] Web sockets and existing HTTP stacks

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:
> On Tue, 22 Dec 2009, Greg Wilkins wrote:
>> Mark Nottingham wrote:
>>> There was a fairly long thread initiated by Ian on squid-dev, FYI:
>>>   http://marc.info/?t=124700786100001&r=1&w=2
>>>
>>> That discussion is very similar to this one.
>> This is looking more an more like a hostile takeover bid of port 80.
> 
> Just so we're clear, Web Sockets (then TCPConnection) was originally 
> completely independent of HTTP. It was then requested that the handshake 
> be made HTTP-compatible such that an HTTP server could share its port with 
> a Web Sockets server, so that port 443 could be used (needed to get around 
> man-in-the-middle proxies). Even then, though, the Web Sockets spec 
> originally specifically discouraged the use of port 443 and recommended 
> the use of ports 81 and 815. It was only in response to feedback 
> suggesting that discouraging port 443 was a bad idea that the spec was 
> changed to be neutral on the matter. Then I tried registering ports 81 and 
> 815 and the IANA told me to just use ports 80 and 443.
> 
> So describing this as a "hostile takeover bid" is rather revisionist.

OK fair cop - a bit of an exaggeration.

But now that you have been encouraged to use port 80, then you need
to play by the existing rules on port 80 - up until the time the
upgrade response is sent.   After that, you can go crazy with the
cheeze-whiz on new protocol and any intermediary that does pass
the upgrade, but does not handle the subsequent traffic is in the wrong.

But prior to the upgrade response, you are in HTTP and should be
governed by RFC2616 and not just pretend HTTP.

> It's 
> only through three years of responding to feedback that we've reached this 
> point, and I've done my best to ensure that the handshake really is 
> compatible with HTTP 

Why "compatible with HTTP"?   Why not just be real HTTP prior to the
upgrade?

> to the extent necessary to handle the use cases that
> people have brought to the table.

This list and the squid list and other forums are full of people
raising use-cases that are not supported.    This thread was
started by a post about a C HTTP stack that had difficulty
with the "compatible HTTP", I've posted similar issues with
the Jetty implementation.   The squid list shows how
a caching proxy is having problems with just "compatibility"
and there have been plenty of other use-cases listed
about load balancers, SSL offload, etc. etc.

You have been entirely unsuccessful in convincing anybody
else of the validity of your assertion that binary specified
upgrade requests/responses increases security or serves
any purpose at all.  I've not seen 1 word of support for
that approach from anybody else.

So I'm sorry about the hostile take over bid comment, but
it just reflects my frustration at your intransigence on
this issue.    When existing HTTP infrastructure on port
80 is incompatible with your new protocol, your response
is that we should not use that infrastructure on port 80!

But that is simply not an option.

regards