W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

HTTP, websockets, and redirects

From: Thomas Roessler <tlr@w3.org>
Date: Sun, 24 Jul 2011 09:52:59 -0400
Message-Id: <B223E878-36A5-47DD-AF7B-8A149F711BBA@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>
To: public-ietf-w3c@w3.org, WebApps WG <public-webapps@w3.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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT