[whatwg] Issues with Web Sockets API
jorlow at chromium.org
Tue Jul 28 21:43:06 PDT 2009
On Tue, Jul 28, 2009 at 8:57 PM, Alexey Proskuryakov <ap at webkit.org> 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
> Redirects surely add a lot of complexity though.
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
I definitely agree these are good items for v2, but I think what's already
in the spec is a good start.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg