Re: [hybi] More feedback on WebSockets

[Mark Nottingham <[e-mail]>]

On 27/10/2009, at 8:37 PM, Ian Hickson wrote:
>>
>> 2) The handshake protocol looks like HTTP, but is not (e.g., it's  
>> case-
>> sensitive and whitespace-sensitive). However, you define the default
>> ports for WS and WSS to be port 80 and 443, respectively.
>>
>> These ports are reserved for HTTP, at least initially; while you  
>> can use
>> HTTP to upgrade to a different protocol, defining a
>> HTTP-like-but-not-really-HTTP handshake protocol to run over them
>> initially conflicts with the designated use of the port.
>
> IANA told me to use ports 80 and 443 for WebSocket. See IANA ticket
> #257455. (I had originally requested new ports, ideally 81 and 815.)
>
> I disagree that the current handshake isn't like HTTP enough, though.

I didn't say it isn't like it (in fact, I specifically said it is); I  
said that it isn't HTTP.

Just as Starbucks is like coffee, but not; or a vehicle that only  
allows you to turn the steering wheel left is like a car, but not.  
There are many more examples I could produce, but decency suggests I  
stop.

You've effectively profiled the syntactic conventions of HTTP.  
Implementations that speak HTTP -- whether profiled or not -- should  
be able to do so confidently on the port allocated to it.


> The
> request is fully HTTP-compliant. What value would there be in  
> relaxing the
> rules on what WebSocket clients should send in the request? I don't
> understand the real-world case you are concerned about.

My concern is with the precedent it will set.

As far as real-world use cases, I think that your handshake has a  
significant chance of producing false positives with deployed systems;  
many so-called "transparent" (interception) proxies often take great  
pains to stay hidden, so that while the client and server will think  
they have an operative WebSocket connection, as soon as they try to do  
any bi-directional (i.e., not request/response) communication, it will  
fail in a non-obvious, slow way (e.g., hanging) that's hard to recover  
from.

You'd be better off using a handshake that looks as little like HTTP  
as possible, so as to fail more reliably and quickly. Or, preferably,  
another port.


>> 3) In section 1.6 (Establishing a Connection), you say
>>
>>> On the face of it, the simplest method would seem to be to use port
>>>   80 to get a direct connection to a Web Socket server.  Port 80
>>>   traffic, however, will often be intercepted by HTTP proxies, which
>>>   can lead to the connection failing to be established.
>>
>> Given this, is it a good idea for the default port for the WS  
>> scheme to
>> be port 80? Why not use a separate port and fall back to 443 with  
>> null
>> encryption, for example?
>
> That's what the spec used to require, but IANA requested that I use  
> ports
> 80 and 443 directly.

What was the reasoning behind this request? The ticket number you  
refer to isn't useful to those not involved.


> and how do I indicate that multiple subprotocols are in use on one
>> connection?
>
> Only one protocol can be in use per connection. If your protocol is  
> just
> another layer below the final application-level protocol, then your
> protocol would have its own equivalent mechanism.

Hmm. This seems like punting the problem to yet another layer.  
However, I do agree that offering a complete solution in WS is  
difficult at best.


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