[whatwg] Issues with Web Sockets API

[Ian Hickson]

On Tue, 28 Jul 2009, Alexey Proskuryakov wrote:
> 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.

I've added support for redirects. While I was at it I also added support 
for authentication.

So far I've only changed the client handshake part of this, I expect in 
time I'll update the intro and the server-side part, but I wanted to get 
feedback on the client-side part first.


> > > 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.

The text "Closing the connection causes a close event to be fired and the 
readyState attribute's value to change, as described below" is not 
normative (it has no "must"s in it). It's just letting you know that 
subsequent requirements as described lower in the spec do result in that.

Is there some way I can make that clearer?


On Tue, 28 Jul 2009, Jeremy Orlow wrote:
> 
> They can be implemented at the application layer though, right?  I 
> suppose this does add complexity, but it doesn't seem like it'd add 
> _that_ much. Especially if you're already doing authentication at the 
> application level as well.
> 
> I definitely agree these are good items for v2, but I think what's 
> already in the spec is a good start.

It ended up not adding too much, so I just went ahead and added it now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'