[whatwg] Issues with Web Sockets API
ap at webkit.org
Tue Jul 28 20:57:13 PDT 2009
28.07.2009, в 16:40, Ian Hickson написал(а):
>> 3) A Web Sockets server cannot respond with a redirect to another
>> 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
>> 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
> 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
Redirects surely add a lot of complexity though.
>> 10) Web Socket handshake uses CRLF line endings strictly. Does this
>> much to security? It prevents using telnet/netcat for debugging,
>> is something I personally use often when working on networking
>> 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
>> closed. For example:
>> - 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
More information about the whatwg