[whatwg] Issues with Web Sockets API

[Alexey Proskuryakov]

06.07.2009, в 21:30, Ian Hickson написал(а):

>> postMessage() may want another exception condition... 'too much data
>> pending exception'... consider calling postMessage in a while(true)
>> loop... at some point the system is going to have to give up queing  
>> the
>> data if its not actually making its way out on the wire.
>
> The spec doesn't specify how UAs are to handle hitting hardware
> limitations or system limitations, because it's often difficult to  
> truly
> control how those cases are handled.


I agree with Michael that send() should not silently drop data that  
could not be sent. It is very easy to fill send buffers, and if bytes  
get silently dropped, implementing app-level acks becomes quite  
difficult. With TCP, the basic guarantee is that bytes are not lost  
until the connection is lost, so app-level acks only require  
confirming the last processed command, and losing this guarantee would  
be quite unfortunate. Most (all?) system TCP implementations certainly  
have ways to deal with flow control.

However, I do not think that raising an exception is an appropriate  
answer. Often, the TCP implementation takes a part of data given to  
it, and asks to resubmit the rest later. So, just returning an integer  
result from send() would be best in my opinion.

The thread has such a nice title that I'm going to throw some  
additional issues in :)

1) Web Sockets is specified to send whatever authentication  
credentials the client has for the resource. However, there is no  
challenge-response sequence specified, which  seems to prevent using  
common auth schemes. HTTP Basic needs to know an authentication realm  
for the credentials, and other schemes need a cryptographic challenge  
(e.g. nonce for Digest auth).

2) It is not specified what the server does when credentials are  
incorrect, so I assume that the intended behavior is to close the  
connection. Unlike HTTP 401 response, this doesn't give the client a  
chance to ask the user again. Also, if the server is on a different  
host, especially one that's not shared with an HTTP server, there  
isn't a way to obtain credentials, in the first place.

I'm not sure how to best handle this, other than to copy more HTTP  
behaviors.

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.

4) "If the user agent already has a Web Socket connection to the  
remote host identified by /host/ (even if known by another name), wait  
until that connection has been established or for that connection to  
have failed."

It doesn't look like "host identified by /host/" is defined anywhere.  
Does this requirement say that IP addresses should be compared,  
instead of host names? I'm not sure if this is significant for  
preventing DoS attacks, and anyway, the IP address may not be known  
before a request is sent. This puts an unusual burden on the  
implementation.

5) We probably need to specify a keep-alive feature to avoid proxy  
connection timeout. I do not have factual data on whether common  
proxies implement connection timeout, but I'd expect them to often do.

6) The spec should probably explicitly permit blocking some ports from  
use with Web Sockets at UA's discretion. In practice, the list would  
likely be the same as for HTTP, see e.g. <http://www.mozilla.org/projects/netlib/PortBanning.html 
 >.

7) "use a SOCKS proxy for WebSocket connections, if available, or  
failing that, to prefer an HTTPS proxy over an HTTP proxy"

It is not clear what definition of proxy types is used here. To me, an  
HTTPS proxy is one that supports CONNECT to port 443, and an HTTP  
proxy (if we're making a distinction from HTTPS) is one that  
intercepts and forwards GET requests. However, this understanding  
contradicts an example in paragraph 3.1.3, and also, it's not clear  
how a GET proxy could be used for Web Sockets.

8) Many HTTPS proxies only allow connecting to port 443. Do you have  
the data on whether relying on existing proxies to establish  
connections to arbitrary ports is practical?

9) "There is no limit to the number of established Web Socket  
connections a user agent can have with a single remote host".

Does this mean that Web Socket connections are exempt from the normal  
4-connection (or so) limit? Why is it OK?

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.

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.

As Web Sockets are basically at the same level as TCP, and TCP  
provides complete info about socket state, I don't think that  
delegating connection closing to app-level protocols would be  
appropriate.

- WBR, Alexey Proskuryakov