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.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 Monday, 29 August 2011 16:30:28 UTC