On Thu, 22 Jul 2010 22:18:46 +0200, Ian Hickson <i...@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 <sim...@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
