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
