This issue was discussed on some mailing list a while back (I forget which). The consensus seemed to be that redirects are the source of a large number of security vulnerabilities in HTTP and we'd like users of the WebSocket API to handle them explicitly.
I'm not sure I understand your question regarding WebRTC, but the general answer to that class of questions is that WebRTC relies, in large part, on ICE to be secure against cross-protocol and voicehammer attacks. Adam On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roessler <[email protected]> wrote: > The hybi WG is concerned about the following clause in the websocket API spec: > >> When the user agent validates the server's response during the "establish a >> WebSocket connection" algorithm, if the status code received from the server >> is not 101 (e.g. it is a redirect), the user agent must fail the websocket >> connection. > > http://dev.w3.org/html5/websockets/ > > Discussion with the WG chairs: > > - this looks like a conservative attempt to lock down redirects in the face > of ill-understood cross-protocol interactions > - critical path for addressing includes analysis of interaction with XHR, > XHR2, CORS > - following redirects in HTTP is optional for the client, therefore in > principle a decision that a client-side spec can profile > - concern about ability to use HTTP fully before 101 succeeds, and future > extensibility > > Salvatore and Gabriel will bring this up later in the week with websec, and > we'll probably want to make it a discussion with Webappsec, too. > > Side note: Does WebRTC have related issues concerning multiple protocols in a > single-origin context? Are there lessons to learn from them, or is the case > sufficiently different that we need a specific analysis here? > > Thanks,
