Re: Hello from Mozilla

On 07/14/2009 04:38 PM, Henrik Nordstrom wrote:
> 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.

I strongly agree with this. Frankly, I suspect (hope?) that IETF gurus
would prevent publishing an RFC that kind of reuses the HTTP Upgrade
mechanism but then declares many compliant Upgrade exchanges invalid.

If you think your approach is the right one, I would suggest openly
discussing it with the right IETF folks as early as possible, to avoid
wasting your time on an idea they will be blocked later.

HTTP "hard-coding" seems to be a small, albeit critical, part of
WebSocket so changing it to avoid conflicts with HTTP may be possible
without significant negative effects on the rest of the draft.

Good luck,

Alex.

> 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 - 23:56:00 MDT