[whatwg] WebSockets feedback

[Simon Pieters]

On Thu, 22 Jul 2010 22:18:46 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 22 Apr 2010, Simon Pieters wrote:
>>
>> WebSocket data framing
>>
>> [[
>> 8. If the frame type is 0xFF and the length was 0, then run the  
>> following
>> substeps:
>> ]]
>>
>> This will be true for 0xFF 0x80 0x00, or any number of leading 0x80  
>> bytes in
>> length. Presumably the frame should only be treated as a closing  
>> handshake if
>> it was 0xFF 0x00.
>
> Why?

Because I expected the closing frame to be the exact sequence 0xFF 0x00  
and nothing else. It makes the protocol simpler to understand and explain.


> On Thu, 22 Apr 2010, Simon Pieters wrote:
>>
>> establishing a WebSocket connection:
>>
>> [[
>> 41. ... or if there are any entries in the fields list whose names are  
>> the
>> empty string, then fail the WebSocket connection and abort these steps.  
>> ...
>> ]]
>>
>> I think it is better to check for this while parsing the fields, by  
>> checking
>> if the name byte array is empty here:
>>
>> [[
>> 34. Read a byte from the server.
>>
>> ...
>> If the byte is 0x3A (ASCII :)
>> Move on to the next step.
>> ]]
>
> Why?

This was moot.


> On Thu, 6 May 2010, Simon Pieters wrote:
>> On Tue, 20 Apr 2010 16:00:36 +0200, Simon Pieters <simonp at opera.com>  
>> wrote:
>>
>> > [[
>> > WebSocket object with an open connection must not be garbage  
>> collected if
>> > there are any event listeners registered for message events.
>> > ]]
>> >
>> > Shouldn't it also not be garbage collected if there are listeners for  
>> open,
>> > error and close? What about when the connection is not yet  
>> established?
>>
>> I think the policy should be:
>>
>> if readyState is CONNECTING:
>>  has 'open' event listener: don't collect
>>  has 'message' event listener: don't collect
>>  has 'error' event listener: don't collect
>>  has 'close' event listener: don't collect
>>
>> if readyState is OPEN:
>>  has 'open' event listener: OK to collect
>>  has 'message' event listener: don't collect
>>  has 'error' event listener: don't collect
>>  has 'close' event listener: don't collect
>>
>> if readyState is CLOSING:
>>  has 'open' event listener: OK to collect
>>  has 'message' event listener: OK to collect
>>  has 'error' event listener: OK to collect
>>  has 'close' event listener: don't collect
>>
>> if readyState is CLOSED:
>>  has 'open' event listener: OK to collect
>>  has 'message' event listener: OK to collect
>>  has 'error' event listener: OK to collect
>>  has 'close' event listener: OK to collect
>
> Agreed.

Please see  
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026400.html


> On Tue, 20 Jul 2010, Simon Pieters wrote:
>>
>> The WebSocket spec restricts the value of the subprotocol that the
>> client is allowed to send to the server (see step 3 in the WebSocket()
>> constructor algorithm). However there's no restriction on the server
>> side (see step 2 of Sending the server's opening handshake). The client
>> could not have asked for any subprotocol, but the server can still
>> respond with a subprotocol, and the connection will be accepted.
>>
>> Shouldn't the server have the same restriction as the client?
>
> The idea is that the client can try to connect to a server without  
> knowing
> what protocol it supports at all, and find out what protocol it supports.
> This also allows servers to be updated to list a subprotocol in
> preparation for supporting multiple subprotocols, without having to
> explicitly hide the subprotocol declaration in the case when the UA  
> didn't
> specify one.

The problem I was discussing is the following scenario:

1. Client opens a websocket without any specified subprotocol.
2. Server replies with subprotocol 'räksmörgås'.
3. Client accepts the connection.

Next time, the client cannot open a websocket with the subprotocol that  
the server used, since räksmörgås is non-ascii and will raise an exception  
if used in the constructor. Hence, I think the server should only be  
allowed to use ascii subprotocols (without spaces) to conform to the spec.

-- 
Simon Pieters
Opera Software