- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Tue, 28 Jul 2009 21:43:06 -0700
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 > functionality. > > 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 as well. 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... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/3d2eca56/attachment-0001.htm>
Received on Tuesday, 28 July 2009 21:43:06 UTC