[whatwg] Issues with Web Sockets API

28.07.2009, ? 16:40, Ian Hickson ???????(?):

>> 3) A Web Sockets server cannot respond with a redirect to another  
>> URL.
>> I'm not sure if the intention is to leave this to implementations,  
>> or to
>> add in Web Sockets v2, but it definitely looks like an important  
>> feature
>> to me, maybe something that needs to be in v1.
>
> What's the use case? Why does this need to be at the connection layer
> rather than the application layer? (Why would we need this, when TCP
> doesn't have it? Would you also need "redirect"-like functonality in  
> IRC,
> IMAP, SSH, and other such protocols?)

Just like with HTTP, redirects will make it possible to move services  
to a different location. I guess the use cases are exactly the same  
that tell us that we should allow redirects with cross-site  
XMLHttpRequest (but I can't enumerate those).

Other protocols do not get accessed from Web pages, so transparent  
redirect support is not needed to keep web apps working after services  
they use move. The Web has redirects all over the place, and WebSocket  
has "Web" in its name :)

Finally, since it's likely that WebSocket servers will share ports  
with HTTP ones, one can expect that returning a 307 for all requests  
(including those with Upgrade: WebSocket) will be enough to preserve  
application functionality.

Redirects surely add a lot of complexity though.

>> 10) Web Socket handshake uses CRLF line endings strictly. Does this  
>> add
>> much to security? It prevents using telnet/netcat for debugging,  
>> which
>> is something I personally use often when working on networking  
>> issues.
>>
>> If there is no practical reason for this, I'd suggest relaxing this
>> aspect of parsing.
>
> Do you mean client->server or server->client?

Originally, I meant both, but now I've been told that telnet on Mac OS  
X translates line breaks to CRLF by default (even though it's not  
telnet's own default, according to man page). Netcat doesn't perform  
such translation, so simulating a server with netcat won't work unless  
plain CR is allowed.

Other platforms and tools commonly used for HTTP debugging may have  
different defaults and limitations. This is not a huge deal, of course.

>> 11) There is no way for the client to know that the connection has  
>> been
>> closed. For example:
>> - socket.close() is called from JavaScript;
>> - onclose handler is invoked;
>> - more data arrives from the server, and onmessage is dispatched  
>> (which I
>> think is correct, and it matches what TCP does);
>> - finally, a TCP FIN arrives, indicating that there will be no more  
>> data from
>> the server (the underlying TCP connection is in TIME_WAIT state  
>> after that);
>> - the client never learns that the server is done sending data.
>
> The onclose only fires once the connection has closed, which is  
> after the
> TCP FIN, so it happens after the last 'message' event.

Maybe this could be clarified in the spec. The current text is:

"The close() method must close the Web Socket connection or connection  
attempt, if any. If the connection is already closed, it must do  
nothing. Closing the connection causes a close event to be fired and  
the readyState attribute's value to change, as described below."

I was reading it as a requirement to immediately change readyState to  
CLOSED, and to fire a close event. If all this happens asynchronously  
after the server agrees to close the connection, then my example will  
work fine, of course.

- WBR, Alexey Proskuryakov

Received on Tuesday, 28 July 2009 20:57:13 UTC