[whatwg] Simon's WebSocket feedback

[Ian Hickson]

On Thu, 1 Apr 2010, Simon Pieters wrote:
>
> The establish a WebSocket connection algorithm says:
> 
> [[
> 35. ...
> 
> ↪If the byte is 0x20 (ASCII space)
> Ignore the byte and move on to the next step.
> 
> Otherwise
> Treat the byte as described by the list in the next step, then move on to that
> next step for real.
> 
> Note: This skips past a space character after the colon, if necessary.
> 
> 36. Read a byte from the server.
> 
> If the connection closes before this byte is received, then fail the WebSocket
> connection and abort these steps.
> 
> Otherwise, handle the byte as described in the appropriate entry below:
> 
> ↪If the byte is 0x0D (ASCII CR)
> Move on to the next step.
> ]]
> 
> Consider the case when the server gives a colon followed by CR. My reading is
> that step 36 will be run twice:
> 
> Upon receiving the CR in step 35, "Treat the byte as described by the list in
> the next step" which is "Move on to the next step." (i.e. step 37), "then move
> on to that next step for real." (i.e. step 36).

Yeah that's very confusing. Fixed.


> Step 41 says:
> 
> [[
> If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related
> field name
> 
> If the relevant specification is supported by the user agent, handle the
> cookie as defined by the appropriate specification, with the resource being
> the one with the host host, the port port, the path (and possibly query
> parameters) resource name, and the scheme http if secure is false and https if
> secure is true. [COOKIES]
> ]]
> 
> What should be done if the relevant specification is not supported?

Nothing.


On Wed, 7 Apr 2010, Simon Pieters wrote:
>
> WebSocket constructor says:
> 
> [[
> 2. If port is a port to which the user agent is configured to block access,
> then throw a SECURITY_ERR exception. (User agents typically block access to
> well-known ports like SMTP.)
> ]]
> 
> Should port 80 be blocked for wss:? Should port 443 be blocked for ws:? 
> Please state explicitly.

Done.


On Thu, 8 Apr 2010, Simon Pieters wrote:
>
> WebSockets constructor:
> 
> [[
> 4. Let origin be the ASCII serialization of the origin of the script that
> invoked the WebSocket() constructor, converted to ASCII lowercase.
> ...
> 6. Establish a WebSocket connection...
> ]]
> 
> which says
> 
> [[
> 13. Add the string consisting of the concatenation of the string "Origin:", a
> U+0020 SPACE character, and the origin value, converted to ASCII lowercase, to
> fields.
> ...
> 41. ...
> If the entry's name is "sec-websocket-origin"
> If the value is not exactly equal to origin, converted to ASCII lowercase,
> then fail the WebSocket connection and abort these steps. [ORIGIN]
> ]]
> 
> Isn't it enough to convert it to lowercase once, in the constructor?

Fixed.


> Sending the server's opening handshake says
> 
> [[
> origin
> The ASCII serialization of the origin that the server is willing to
> communicate with. If the server can respond to requests from multiple origins
> (or indeed, all origins), then the value should be derived from the client's
> handshake, specifically from the "Origin" field. [ORIGIN]
> ]]
> 
> Shouldn't the server convert the origin to lowercase if that's the format the
> client expects? Or should the client accept case-insensitive origin instead?

Good point. Fixed.


On Fri, 9 Apr 2010, Simon Pieters wrote:
>
> WebSocket send() says:
> 
> [[
> The send(data) method transmits data using the connection. If the readyState
> attribute is CONNECTING, it must raise an INVALID_STATE_ERR exception. If the
> data argument has any unpaired surrogates, then it must raise SYNTAX_ERR.
> ]]
> 
> If readyState is CONNECTING *and* the data argument has unpaired 
> surrogates, then my literal reading suggests two exceptions should be 
> raised. I assume this is not correct and the spec should include an 
> "Otherwise,".

Fixed.


On Mon, 12 Apr 2010, Simon Pieters wrote:
>
> WebSocket establish a WebSocket connection:
> 
> [[
> 21. Insert spaces1 U+0020 SPACE characters into key1 at random positions.
> 
> Insert spaces2 U+0020 SPACE characters into key2 at random positions.
> ]]
> 
> It seems a bit risky to insert spaces at the start and at the end of the 
> string; I imagine some servers would ignore them (which would be a bug 
> in the server, but hard to notice since it's random). Maybe we should 
> avoid inserting them at the start and at the end.

Since key1 and key2 can be numbers in the range 1-9, I don't see how to 
avoid at least one of those two places.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'