On Wed, 15 Jul 2009, Adrian Chadd wrote:
> 2009/7/15 Ian Hickson <ian_at_hixie.ch>:
> > 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. `._.-(,_..'--(,_..'`-.;.'Received on Wed Jul 15 2009 - 07:18:58 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 12:00:05 MDT