- From: Brian Raymor <Brian.Raymor@microsoft.com>
- Date: Thu, 25 Aug 2011 18:31:26 +0000
- To: Arthur Barstow <art.barstow@nokia.com>, ext Adam Barth <w3c@adambarth.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Thomas Roessler <tlr@w3.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>
- CC: "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, WebApps WG <public-webapps@w3.org>, Art Barstow <afbarstow@gmail.com>, François Daoust <fd@w3.org>, Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, Tobias Gondrom <tobias.gondrom@gondrom.org>
> On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow < art.barstow@nokia.com> wrote: >> 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. As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be characterized as editorial bugs. Microsoft has no objections to the requirement to fail non-101 responses such as redirects. If there are no further concerns in the working group related to this issue, then the current WebSocket API looks feature complete. I recommend that we publish a Last Call working draft and define a timetable to reach Candidate Recommendation. >> >> 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.ht >> ml >> [Bugs] >> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short >> _de sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=We >> bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr& >> longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_white >> boar >> d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywo >> r ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailt >> ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyex >> act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=d >> oit&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 >> > <Gabriel.Montenegro@microsoft.com> 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.html >> > >> >> Also, 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:w3c@adambarth.com] >> >>> Sent: Sunday, July 24, 2011 13:35 >> >>> To: Thomas Roessler >> >>> Cc: public-ietf-w3c@w3.org; 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<tlr@w3.org> 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, >> >> >
Received on Thursday, 25 August 2011 18:31:57 UTC