On Wed, 15 Jul 2009, Adrian Chadd wrote: > 2009/7/15 Ian Hickson <[email protected]>: > > On Tue, 14 Jul 2009, Alex Rousskov wrote: > >> > >> WebSocket made the handshake bytes look like something Squid thinks it > >> understands. That is the whole point of the argument. You are sending an > >> HTTP-looking message that is not really an HTTP message. I think this is > >> a recipe for trouble, even though it might solve some problem in some > >> environments. > > > > Could you elaborate on what bytes Squid thinks it should change in the > > WebSocket handshake? > > Anything which it can under the HTTP/1.x RFCs.
Could you give some examples? What part of the handshake would Squid change? > Maybe I missed it - why exactly again aren't you just talking HTTP on > the HTTP port(s), and doing a standard HTTP upgrade? WebSocket isn't an HTTP protocol, or subprotocol, it's an independant protocol. The only reason we have an HTTP-Upgrade-like mechanism at all is so that people who want to can share a port with an HTTP server. (i.e. WebSocket doesn't use a standard HTTP Upgrade for the same reason FTP doesn't.) The reason we have a very strict handshake is because we don't want it to be possible to trick a non-WebSocket-aware server into accepting a connection (or similarly, having the client be tricked by the script into accepting a connection to a non-WebSocket-aware server). This is especially important for WebSockets because once there's a connection established, any data might be sent. HTTP is getting similar restrictions, by the way, in the form of the CORS mechanism. Without CORS, scripts can't ever read data back from cross-site HTTP requests they initiate. CORS allows the server to opt in to sending data back to a third-party script. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
