- From: Thomas Roessler <tlr@w3.org>
- Date: Sun, 24 Jul 2011 09:52:59 -0400
- To: public-ietf-w3c@w3.org, WebApps WG <public-webapps@w3.org>
- Cc: Thomas Roessler <tlr@w3.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Art Barstow <afbarstow@gmail.com>, François Daoust <fd@w3.org>, Eric Rescorla <ekr@rtfm.com>, Adam Barth <abarth@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, Tobias Gondrom <tobias.gondrom@gondrom.org>
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, -- Thomas Roessler, W3C <tlr@w3.org> (@roessler)
Received on Sunday, 24 July 2011 13:53:07 UTC