W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > August 2011

RE: HTTP, websockets, and redirects

From: Brian Raymor <Brian.Raymor@microsoft.com>
Date: Wed, 31 Aug 2011 19:43:35 +0000
To: Arthur Barstow <art.barstow@nokia.com>
CC: ext Adam Barth <w3c@adambarth.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Thomas Roessler <tlr@w3.org>, "Salvatore Loreto" <salvatore.loreto@ericsson.com>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, WebApps WG <public-webapps@w3.org>, François Daoust <fd@w3.org>, Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, Tobias Gondrom <tobias.gondrom@gondrom.org>
Message-ID: <61058FE4146DA54D8F2D7BF5495B77221DEB7113@TK5EX14MBXC136.redmond.corp.microsoft.com>
Hi Art,

I've updated the bug. Microsoft is fine with this new validation requirement. In the absence of other comments, I suggest that we update the draft and move on to Last Call.

...Brian


> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Monday, August 29, 2011 9:30 AM
> To: Brian Raymor
> Cc: ext Adam Barth; Gabriel Montenegro; Thomas Roessler; Salvatore Loreto;
> public-ietf-w3c@w3.org; WebApps WG; François Daoust; Eric Rescorla; Harald
> Alvestrand; Tobias Gondrom
> Subject: Re: HTTP, websockets, and redirects
> 
> Hi Brian, All - I just checked Bugzilla and besides the two editorial type bugs
> (12510 and 13700), bug 13777 was filed against the Web Sockets API on
> August 15:
> 
>    http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777
> 
> Currently, there have been no followup comments on 13777 and I think it
> should be addressed before the LC is published.
> 
> -Art Barstow
> 
> 
> On 8/25/11 2:31 PM, ext Brian Raymor wrote:
> >> 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.h
> >>> t
> >>> ml
> >>> [Bugs]
> >>>
> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&shor
> >>> t _de
> >>>
> sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=
> We
> >>>
> bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubs
> tr
> >>> bSocket+API+&
> >>>
> longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whit
> >>> e
> >>> boar
> >>>
> d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&ke
> yw
> >>> o r
> >>>
> ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&em
> ailt
> >>>
> ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=any
> e
> >>> x
> >>>
> act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtyp
> e=
> >>> 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 Wednesday, 31 August 2011 19:44:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 August 2011 19:44:06 GMT