Re: [hybi] A WebSocket handshake

[Maciej Stachowiak <[e-mail]>]

On Oct 8, 2010, at 2:50 PM, Adam Barth wrote:

> On Fri, Oct 8, 2010 at 2:41 PM, Maciej Stachowiak <[e-mail]> wrote:
>> On Oct 8, 2010, at 2:28 PM, Adam Barth wrote:
>>> On Fri, Oct 8, 2010 at 2:10 PM, Maciej Stachowiak <[e-mail]> wrote:
>>>> I like the general approach (based on CONNECT and encrypting the data
>>>> stream), it seems more robust than depending on the details of error
>>>> handling code.
>>> 
>>> Thanks.  I think we can use the encrypted additional information sent
>>> with the initial handshake to address the concerns you express above.
>> 
>> It would be good to spell out the details of what additional information is
>> sent and how. Then we could evaluate how much of a burden it would be for
>> multiplexing servers to dispatch between HTTP and WebSocket, to dispatch to
>> the right virtual host for WebSocket connections, and to dispatch among the
>> "servlets" (or equivalent) that implement individual WebSocket resources.
>> It seems like they would have to handle this differently than how it's
>> currently done for HTTP, it would be useful to understand how different.
> 
> Ok.  We have a lot of flexibility in this regard.  If you like the
> format of the current handshake, you could include the following in
> the additional information (encrypted as described in the document):
> 
>        GET /demo HTTP/1.1
>        Host: example.com
>        Sec-WebSocket-Protocol: sample
>        Origin: http://example.com
> 
> You can also include cookies or whatever else you like.  There are
> only two constraints:
> 
> 1) You don't want to include too many bytes to avoid spamming servers
> with too much traffic before they've agreed to the connection.
> 
> 2) You probably don't want to send message frames until the server
> accepts the connection.  The reason for this is to let simple servers
> just spam back the one-and-only origin they want to accept connections
> from.  If we hold off on message frames until the handshake finishes,
> the browser stops the attacker from sending them messages.  Otherwise,
> they have to actively ignore messages from origins they don't like.

Sounds reasonable. What's interesting about this kind of approach is that it would let servers feed back the second set of headers into their usual host/resource dispatch code. This may make modifications for WebSocket-awareness somewhat simpler.

REgards,
Maciej