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< [email protected]>
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
<[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.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:[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 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,
