- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 22 Jul 2010 23:48:07 +0200
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
Received on Thursday, 22 July 2010 14:48:07 UTC