[whatwg] Redirects and draft-hixie-thewebsocketprotocol

[Ian Hickson]

On Sat, 8 Aug 2009, Adam Barth wrote:
> 
> In fact, the situation is worse than the above because the websocket 
> protocol supports cookies.  Instead of relying on a firewall and IP 
> authentication, the victim server could be on the public Internet and be 
> relying upon cookie authentication.
> 
> I think there are a number of ways of resolving this issue:
> 
> 1) We could use Sec-From instead of Origin because Sec-From implicates 
> the full redirect chain instead of just the origin that initiated the 
> request.  On IRC, Ian said he doesn't like this choice because servers 
> might not validate this header properly.

My concern here is that to confirm the server is checking Sec-From we'd 
want the server to include some sort of response, and I'm not really sure 
what that would be. Maybe just WebSocket-Sec-From: ..., where it contains 
the same value as Sec-From, but Sec-From only gets included on redirects?


> 2) Instead of handling the redirect inside the websocket protocol, we 
> can report the redirect back to the web site making the request (in this 
> case example.com).  Then the trustworthy web site would then have the 
> option of following or not following the redirect.  If we did this, we 
> would have to ensure that the redirecting server understands the 
> websocket protocol (probably by requiring it to send WebSocket-Origin or 
> some such) to avoid leaking the targets of already-existing redirects.  
> Also, it's unclear on what basis the web site would decide whether to 
> follow the redirect.
>
> 3) We could restrict redirects to the same origin.  This has the 
> disadvantage of not covering the full use case of redirects.
> 
> 4) We could remove support for redirects.

On Sun, 9 Aug 2009, Jeremy Orlow wrote:
>
> I feel like redirects add unnecessary complexity.
> 
> We're already asking application developers to handle ACKing, keep 
> alives, multi-plexing, connection limiting, authentication, etc 
> themselves.  To me, it doesn't seem like much of an additional burden to 
> ask them to handle redirects.  And by keeping the spec simple, I think 
> we'll increase the chances of quick adoption by UAs, which will speed up 
> the adoption by web apps, which will give us feedback on what features 
> web developers actually want much quicker.

The use case for redirects is if Google (say) provides a WebSocket service 
that lots of sites around the Web uses, and then Google wants to move the 
service to another host, without transparent redirects, all the pages 
using the service will break until they can be updated, whereas with 
redirects, we can just redirect and be done with it.


I've removed redirect support for now, but I think we should have support 
for it at some point.

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