Re: Hello from Mozilla

ons 2009-07-08 klockan 07:00 +0000 skrev Ian Hickson:

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

If you use HTTP Upgrade as the initial handshake mechanism and expect
this to be layered ontop of HTTP servers then you SHOULD use HTTP for
this sequence. What takes place after the HTTP/1.1 response to the
Upgrade is entirely yours, but until then it's HTTP. Hardcoding this
sequence is just silly, and will cause a lot of trouble later on.

You already touch some aspects of HTTP such as authentication. Now throw
things like NTLM or Digest authentication into the mix and you will
quickly find that the current specification is a bit too limiting if the
intention is that the upgrade requests should be processed by an HTTP
server.

Also regarding HTTP Upgrade semantics. If you want to follow that model
then there is not really any relation between the initial Upgrade
request and what takes place after the upgrade has completed. It's a
complete switch of protocols, with their own semantics.

Regards
Henrik
Received on Tue Jul 14 2009 - 22:39:01 MDT