On Tue, Mar 29, 2011 at 10:34 AM, Adam Barth w...@adambarth.com wrote:
In this HyBi thread:
http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html
Folks are arguing that the WebSocket protocol should support HTTP
redirects during the handshake and that dealing with the security
consequences of redirects should be dealt with at the API layer.
If/when that occurs, we should update the API layer to deal with the
security consequences of the WebSocket protocol following HTTP
redirects, preferably by aborting any WebSocket connections that the
server attempts to redirect.
I absolutely agree that redirects are a big source of security
problems. If we are going to support them for websocket then I think
we need to learn from the mistakes of http as to not repeat the
problems that occurred there.
One solution could be to add a redirect API on the WebSocket
interface. By default we would not follow the redirect but instead
fire an event on the WebSocket object. The event would contain the URL
which the server wants to redirect to. Only if the page explicitly
signals that it wants to follow the redirect would we do so.
This signaling could be done by calling .preventDefault() on the
event, or by calling some .yesPleaseFollowRedirect() function on the
event. It could also be done by making the implementation close the
websocket object before firing the event, but allowing the page to
call .open on the object and pass in an arbitrary url, for example the
url which was received from the redirect event.
But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now.
/ Jonas
