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
