W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] WebSockets and redirects

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 29 Mar 2011 15:12:04 -0700
Message-ID: <AANLkTikRXRZ2rBmBgbD5DA-96GO0+jgTEp+uX990WQoQ@mail.gmail.com>
On Tue, Mar 29, 2011 at 10:34 AM, Adam Barth <w3c at 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
Received on Tuesday, 29 March 2011 15:12:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC