Re: [hybi] More feedback on WebSockets

[Ian Hickson <[e-mail]>]

On Wed, 28 Oct 2009, Mark Nottingham wrote:
> 
> 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.

Could you give a concrete example of where this wouldn't work? I don't 
understand the problem here.


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

Could you elaborate on this?


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

Yes, this is a known risk. The solution is to use TLS. It's not clear that 
there is any way around this without sacrificing some of the other 
requirements (like being able to share a port with an HTTP server).

If anyone can provide any information on any specific MITM proxies that 
have this problem, I would be very grateful. I would love to be able to 
test this in real-world situations against such proxies.


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

The relevant goal here is to be able to share a port with an HTTP server. 
Not doing an HTTP Upgrade and not using the same port both rather fail to 
achieve this goal.


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

I didn't really understand their reasoning, but they insisted that it was 
the right thing even when I asked for confirmation.


> The ticket number you refer to isn't useful to those not involved.

I haven't checked, but I assume that the number would let you find the 
issue in the IANA's archives... the number was in the subject line of the 
e-mails, if that helps.


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

WebSocket's entire design is to punt everything to the next layer. It's 
not trying to add any features to the network; it's just trying to provide 
the closest thing to raw TCP as possible to JavaScript, within the 
constraints of the Web (browser) platform: the origin security model, the 
lack of binary support, and the event-based (rather than stream-based) 
programming model.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'