
Firefox 6 - WebSockets are back - thefox
http://hacks.mozilla.org/2011/05/aurora-6-is-here/
======
riobard
Firefox 4 ditched WebSockets for security reasons. Does anybody know the
justification to add it back now? More specifically, do they fix the security
issue of WebSocket, or do they just give up to the popular demand?

~~~
wmf
Yes, the security concern has been fixed using masking.
[http://tools.ietf.org/html/draft-ietf-hybi-
thewebsocketproto...](http://tools.ietf.org/html/draft-ietf-hybi-
thewebsocketprotocol-07#section-4.3)

~~~
palish
Maybe someone could explain the original security concern, and how masking is
able to address that concern?

~~~
tptacek
In the original protocol, it was possible to get two endpoints to transact
over Websockets even if a middlebox between them didn't perfectly enforce the
protocol. This is bad because it potentially confuses the middlebox about
which parts of the stream are HTTP/1.1 requests or not, which can allow
attackers to poison caches.

In the new protocol, Websockets traffic is (trivially) encoded so that it (a)
can't accidentally be interpreted by either endpoint as something other than
Websockets and (b) can't confuse middleboxes.

Basically, "new" Websockets has custom Websockets encryption that nothing
other than Websockets will be speaking, so, if you're talking Websockets, it's
because both endpoints consented to do so.

~~~
tomjen3
That seems like a horrible solution - now we have to wait until all companies
update their proxies to support websockets.

~~~
mbrubeck
No, just the opposite - this change was necessary to get WebSockets to _work_
with old, broken proxies. Previously those proxies might interpret part of the
body of the WebSocket traffic as an HTTP header; now they will correctly just
pass the traffic through.

------
nkassis
That's good news, WebSockets is probably the second coolest thing to come out
of the HTML5 movement, right after WebGL I think. Everything else is cool and
all but those two are major changes.

~~~
david927
I'm also happy and couldn't agree more, but I would make it more generic:
Canvas/WebGL is the huge change. And I would add Local Storage as a distant
third to WebSockets' strong second. The rest is fun but not game changing.

~~~
palish
Local Storage is limited to 5MB, which cripples the ability of indie game
developers to effectively use WebGL as an alternative deployment platform.

~~~
nextparadigms
It has unlimited storage if you use Chrome's Webstore. I suppose it will just
take a while before the other browsers can figure out how to implement it the
right way for more than 5 MB of storage.

~~~
asadotzler
Other browsers have figured it out. Other browsers had it figured out before
there was a Chrome Webstore.

------
mbrubeck
In case you're wondering what _"this API will be temporarily namespaced"_
means, see <http://bugzil.la/659324>. Before Firefox 6 is pushed to the
release channel, the constructor will will be changed to "new MozWebSocket()".
Once the JavaScript API is stabilized, it will be changed back to "new
WebSocket()".

------
boazsender
Rwaldron has some good coverage of this over at
[http://weblog.bocoup.com/javascript-firefox-aurora-6-and-
eve...](http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eventsource-
api)

Funny, I just posted this link to Rwaldron's coverage right before you posted
to the link he is responding to.

------
trizk
IE does not inherently support WebSockets, so apps with worker threads will
block. You can support WebSockets in IE clients using this hack:

<http://bit.ly/irM6XV>

------
huetsch
What are some potentially practical uses of WebSockets?

~~~
MostAwesomeDude
Anything that Comet or other long-polling techniques provide, really.

The advantages of WebSockets include constantly changing specifications which
are neither backwards- nor forwards-compatible, a lack of proxy traversal, an
arbitrary and unreasonable limitation on binary data transfer, and lack of
unified browser and server support.

~~~
daeken
I've held off on using WebSockets until binary frames are supported. I'm
amazed they haven't been so far.

~~~
yesbabyyes
Ericsson has a working implementation for this, they do voice and video
browser to browser with Webkit:

<https://labs.ericsson.com/apis/web-real-time-communication>

<http://news.ycombinator.com/item?id=2600585>

------
jrockway
I still don't understand "web" sockets. I mean, to get a web page, I already
have a TCP connection. TCP connections are bidirectional. All we need is for
the browser to write stuff to the socket and read stuff from it.

Yes, I understand that proxies may assume HTTP is request/response... but
that's fine. My app breaks when you use that proxy. I can live with that.

The future-proof fix is to add some Cache-control header that says, "hey, this
response is infinitely long! don't cache!".

------
code_duck
Also, the 'Web Console' developer tools are interesting. Somewhat rough at the
moment, but it has some useful features.

~~~
yahelc
I am completely in love with the persistence of the console between pages;
Really, really helpful for a whole bunch of hard-to-debug cases.

------
kunjaan
Do you guys know of good tutorials on WebSockets?

