6 ms·

Firefox 6 - WebSockets are back

147 points by thefox 15y ago

boazsender 15y ago
Rwaldron has some good coverage of this over at http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eventsource-api http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eve... Funny, I just posted this link to Rwaldron's coverage right before you posted to the link he is responding to.
nkassis 15y ago
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 15y ago
  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 15y ago
    Local Storage is limited to 5MB, which cripples the ability of indie game developers to effectively use WebGL as an alternative deployment platform.
    - nextparadigms 15y ago
      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 15y ago
        Other browsers have figured it out. Other browsers had it figured out before there was a Chrome Webstore.
    - windsurfer 15y ago
      You will be able to ask the user for more than 5MB.
    - azakai 15y ago
      > Local Storage is limited to 5MB You can store a lot more than that in IndexedDB. The browser asks the user every 20MB or so.
  - nkassis 15y ago
    Yeah that's true, Canvas is a huge win also. I use both extensively for my current work project. The File Api is also pretty awesome, I'd tie it up to local storage. In the field (Medical imaging) I'm in, allowing users to load data from their computer with no round trip to the server is very important. It helps for security reasons.
- ericflo 15y ago
  I disagree, I think that history.pushState is the most important thing.
  - Skalman 15y ago
    There's a difference between cool and important. pushState isn't that cool as we can almost do the same thing without it (#!), but web sockets are a whole new concept. That said, for sites that don't constantly update, pushState will be more useful than web sockets.
  - extension 15y ago
    ...because history.pushState is what makes it ok to use all the other cool stuff.
riobard 15y ago
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 15y ago
  Yes, the security concern has been fixed using masking. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-4.3 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...
  - palish 15y ago
    Maybe someone could explain the original security concern, and how masking is able to address that concern?
    - tptacek 15y ago
      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.
      - yuhong 15y ago
        To be more precise, obfuscation.
        tptacek 15y ago
        That would indeed be more precise, but it would also be bad writing. And my writing needs all the help it can get.
huetsch 15y ago
What are some potentially practical uses of WebSockets?
- wh-uws 15y ago
  Realtime web apps. No need for long poling when you can have a live connection open
- MostAwesomeDude 15y ago
  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 15y ago
    I've held off on using WebSockets until binary frames are supported. I'm amazed they haven't been so far.
    - yesbabyyes 15y ago
      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 https://labs.ericsson.com/apis/web-real-time-communication http://news.ycombinator.com/item?id=2600585 http://news.ycombinator.com/item?id=2600585
    - MostAwesomeDude 15y ago
      In practice, things like Base64 encoding are used. That's what we use in Ganeti Web Manager to host a noVNC (HTML5 VNC client) and have it talk WebSockets with the backend. In theory, there's no good reason we can't have binary frames; I have internally filed it under the "Why can't we have nice things?" category.
  - dochtman 15y ago
kunjaan 15y ago
Do you guys know of good tutorials on WebSockets?
code_duck 15y ago
Also, the 'Web Console' developer tools are interesting. Somewhat rough at the moment, but it has some useful features.
- yahelc 15y ago
  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.
mbrubeck 15y ago
In case you're wondering what "this API will be temporarily namespaced" means, see http://bugzil.la/659324 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()".
trizk 15y ago
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 http://bit.ly/irM6XV
jrockway 15y ago
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!".

147 points by thefox 15y ago

Rwaldron has some good coverage of this over at http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eventsource-api http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eve... Funny, I just posted this link to Rwaldron's coverage right before you posted to the link he is responding to.

nkassis 15y ago

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 15y ago
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 15y ago
  Local Storage is limited to 5MB, which cripples the ability of indie game developers to effectively use WebGL as an alternative deployment platform.
  - nextparadigms 15y ago
    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 15y ago
      Other browsers have figured it out. Other browsers had it figured out before there was a Chrome Webstore.
  - windsurfer 15y ago
    You will be able to ask the user for more than 5MB.
  - azakai 15y ago
    > Local Storage is limited to 5MB You can store a lot more than that in IndexedDB. The browser asks the user every 20MB or so.
- nkassis 15y ago
  Yeah that's true, Canvas is a huge win also. I use both extensively for my current work project. The File Api is also pretty awesome, I'd tie it up to local storage. In the field (Medical imaging) I'm in, allowing users to load data from their computer with no round trip to the server is very important. It helps for security reasons.
ericflo 15y ago
I disagree, I think that history.pushState is the most important thing.
- Skalman 15y ago
  There's a difference between cool and important. pushState isn't that cool as we can almost do the same thing without it (#!), but web sockets are a whole new concept. That said, for sites that don't constantly update, pushState will be more useful than web sockets.
- extension 15y ago
  ...because history.pushState is what makes it ok to use all the other cool stuff.

riobard 15y ago

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 15y ago
Yes, the security concern has been fixed using masking. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-4.3 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...
- palish 15y ago
  Maybe someone could explain the original security concern, and how masking is able to address that concern?
  - tptacek 15y ago
    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.
    - yuhong 15y ago
      To be more precise, obfuscation.
      - tptacek 15y ago
        That would indeed be more precise, but it would also be bad writing. And my writing needs all the help it can get.

huetsch 15y ago

What are some potentially practical uses of WebSockets?

wh-uws 15y ago
Realtime web apps. No need for long poling when you can have a live connection open
MostAwesomeDude 15y ago
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 15y ago
  I've held off on using WebSockets until binary frames are supported. I'm amazed they haven't been so far.
  - yesbabyyes 15y ago
    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 https://labs.ericsson.com/apis/web-real-time-communication http://news.ycombinator.com/item?id=2600585 http://news.ycombinator.com/item?id=2600585
  - MostAwesomeDude 15y ago
    In practice, things like Base64 encoding are used. That's what we use in Ganeti Web Manager to host a noVNC (HTML5 VNC client) and have it talk WebSockets with the backend. In theory, there's no good reason we can't have binary frames; I have internally filed it under the "Why can't we have nice things?" category.
- dochtman 15y ago

kunjaan 15y ago

Do you guys know of good tutorials on WebSockets?

code_duck 15y ago

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

yahelc 15y ago
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.

mbrubeck 15y ago

In case you're wondering what "this API will be temporarily namespaced" means, see http://bugzil.la/659324 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()".

trizk 15y ago

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 http://bit.ly/irM6XV

jrockway 15y ago

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!".