On Tue, 7 Jul 2009, Alex Rousskov wrote: > > If WebSocket is a new protocol on top of TCP, new TCP ports are > appropriate.
Right. > Like virtually any protocol on top of TCP, WebSocket can then rely on > HTTP CONNECT tunneling mechanism without trying to redefine or narrow it > down. Right. > If WebSocket is a new protocol on top of HTTP, then the talk of ports > seems far less appropriate because HTTP already has commonly used ports. WebSocket is a protocol in its own right; however it "happens" to have a handshake that appears to HTTP servers as an HTTP Upgrade request so that it can share a port with HTTP servers. > The fact that I could not tell which of the above statements is true > based on a quick draft read and things like prohibiting valid HTTP > messages in WebSocket responses worry me, but it is likely I just missed > some important pieces or caveats. I've tried adding a section to the intro to make this clearer. Please let me know if it can be improved further. > >> I have noticed there is something about the Upgrade header in the > >> websocket draft so perhaps that mechanism can be polished to > >> implement a proper protocol switch? Or is that too late? > > > > It actually does support a true HTTP Upgrade also, so that people who > > are already using ports 80 or 443 for HTTP can still use WebSocket if > > they are able to make their servers handle the protocol upgrade. > > As far as I can tell, the protocol does not support true HTTP Upgrade > sequence but just one specific exchange of hard-coded (down to each > octet level!) HTTP messages. This clever hack smells like a layering > violation and can be a real pain to support if the client or server HTTP > stack just happens to generate slightly different messages. Well, the client is a WebSocket client, so it can always generate the exact byte sequence specified in the spec almost by definition. The server side is restrictive, but should be implementable without too much trouble so long as there is a way to register a protocol handler that can prevent the HTTP side of the server from sending any bytes at all as part of the response. I agree that this is suboptimal, but we're somewhat forced into this by one of our security design requirements (that the handshake be very specific to avoid enabling request smuggling or other such behaviour -- basically we really want to be sure we're talking to a WebSocket server at the end of the handshake). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
