Hi All,Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I would characterize them both as editorial [Bugs]. As such, the redirect issue Thomas originally reported in this thread (see [Head]) appears to be the only substantive issue blocking WSAPI Last Call.
If anyone wants to continue discussing this redirect issue for WSAPI, I recommend using e-mail (additionally, it may be useful to also create a new bug in Bugzilla).
As I understand it, the HyBi WG plans to freeze the Web Socket Protocol spec "real soon now" (~August 19?).
-Art Barstow [WSAPI] http://dev.w3.org/html5/websockets/[Head] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.html [Bugs] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=WebSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
On 7/27/11 8:12 PM, ext Adam Barth wrote:
On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro <[email protected]> wrote:Thanks Adam, By discussed on some mailing list, do you mean a *W3C* mailing list?A quick search turned up this message: "But I'm totally fine with punting on this for the future and just disallowing redirects on an API level for now." http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.html I started that thread at Greg Wilkins' recommendation: "This is essentially an API issue for the browser websocket object." http://www.ietf.org/mail-archive/web/hybi/current/msg06954.htmlAlso, allowing the users to handle these explicitly implies that the API does not mandate dropping the connection. Currently, the API does not have this flexibility, nor does it allow other uses of non-101 codes, like for authentication. I understand the potential risks with redirects in browsers, and I thought at one moment we were going to augment the security considerations with your help for additional guidance. If websec has already worked on similar language in some draft that we could reuse that would be great, or, similarly, if we could work with you on that text.We can always add support for explicitly following redirects in the future. If we were to automatically follow them today, we'd never be able to remove that behavior by default. Adam-----Original Message----- From: Adam Barth [mailto:[email protected]] Sent: Sunday, July 24, 2011 13:35 To: Thomas Roessler Cc: [email protected]; WebApps WG; Salvatore Loreto; Gabriel Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald Alvestrand; Tobias Gondrom Subject: Re: HTTP, websockets, and redirects 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 APIspec:When the user agent validates the server's response during the "establish aWebSocket 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'llprobably want to make it a discussion with Webappsec, too.Side note: Does WebRTC have related issues concerning multiple protocols in asingle-origin context? Are there lessons to learn from them, or is the case sufficiently different that we need a specific analysis here?Thanks,
