7 ms·

WebSockets Disabled by default for Firefox 4

74 points by thehodge 16y ago

drivebyacct2 16y ago
Yet another reason Chrome's rolling release auto updates are glorious. (When the protocol is fixed, Chrome users will all have it within a day or two; Firefox users, not so much) Additionally: Nochum's comment is concerning, if accurate: >This is gonna suck since the feature detection will be totally thrown off. >E.g.: >if (WebSocket in window) > ...
- axod 16y ago
  Relying on feature detection alone for WebSocket is a big mistake though. Websocket can fail for a number of reasons - proxies, stupid ISPs that interfere with HTTP traffic etc. In Mibbit, the code is something like this: if(WebSocket in window) { tryWebsocket(); window.setTimeout(function() { if (nothingHappened()) useComet() }, 5*1000); } else { useComet(); } Where comet in this case is keep alive long polling XHR.
  - taitems 16y ago
    That's an interesting way of managing timeouts. Is the 5*1000 intended to just be a more readable way of specifying seconds?
    - mcav 16y ago
      I assume so. I do the same thing.
    - axod 16y ago
      Closure compiles it down to 5000 or 5E3 or whatever is smallest in my build process, so all the browser sees is '5e3'. I find 5*1000 most readable in my source code though.
  - catechu 16y ago
    How can you check if nothing happened?
    - jacquesm 16y ago
      By changing some global variable in the callback and checking if it has changed in 'somethinghappened' (which only gets called after 5 seconds, giving the callback time enough to get called).
  - bradgessler 16y ago
    Libraries like Socket.IO will detect if the connection can be made or not... so this point is moot. Feature detection first, connection detection second, then start degrading the transport until all options are exhausted.
    - axod 16y ago
      Sure. I was just explaining for those who prefer to write things like this themselves.
- ergo98 16y ago
  Yet another reason Chrome's rolling release auto updates are glorious. I like Chrome's silent updates, but the only real difference between it and Firefox is that Firefox informs the user that the update is being applied. Other than that, I'm not sure what you're referring to.
  - drivebyacct2 16y ago
    Chrome updates much more frequently and I think you discount the amount that users ignore the update warnings.
    - jrockway 16y ago
      Of course, the people who know what Chrome is are not the people that ignore the warnings.
      - deleted 16y ago
        [deleted]
      - drivebyacct2 16y ago
        Couldn't disagree more. You'd be shocked at the number of CE/CS majors that ignore Firefox updates and complain about them. My mom uses Chrome on my parents' laptop and my dad uses Firefox. Guess which one is out of date :).
    - chime 16y ago
      Absolutely. I hadn't used one of my PCs for a couple of months and turned it on earlier today to find Chrome was two versions behind (7 vs 9).
- jackvalentine 16y ago
  Isn't Firefox 4 where Mozilla want to start using silent updates?
  - drivebyacct2 16y ago
    Firefox is just playing catchup these days, isn't it? Don't get me wrong, that's fantastic. I think everyone benefits from auto-updates.
- natmaster 16y ago
  Not true. Firefox has auto updates, and will be pushing websockets the moment it gets fixed. Firefox also has the best record for turnout time on security fixes (many being released two days after report), so I doubt that will be slow. From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire... "Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release."
  - drivebyacct2 16y ago
    I don't know what you're calling not true. I never suggested that Firefox wouldn't fix this in a x.1 revision. My point is more than 14% of Firefox users are using a version lower than current stable (and that's not counting who is in the [3.6.0, 3.6.12) range.
roschdal 16y ago
Scandalous.
tieTYT 16y ago
This article didn't provide any more information than the title. Can anyone fill the rest of us in. What are WebSockets and why should I care?
- pjscott 16y ago
  They're bidirectional sockets between the web browser and the server, essentially. They're handy whenever you want messages going back and forth between client and server without a bunch of reconnecting, or really ugly hacks. For example, apps like Etherpad or Apache Wave need to send messages for each editing operation (e.g. keystrokes), and it would really suck if they had to open a new HTTP connection for each one and do long-polling to receive from the server. Websockets make this sort of thing simply a matter of sending and receiving on a socket. Easy. You can fake them with something like Socket.IO, if you want the API and are willing to tolerate unpleasant performance on browsers that don't support it.
  - tjarratt 16y ago
    What's the alternative for browsers that don't support it? If you want to gracefully degrade, then you may have to accept an underperforming solution. I'm using Socket.IO and while I'd rather not have to degrade to Flash for Firefox, if that's what I have to do to get support for Firefox users that haven't enabled websockets, I can live with it.
  - mhitza 16y ago
    WebSockets are ugly hacks on their own. They use HTTP as well for the underlying channel of communication. The only difference is that with the WebSockets the ugliness is hidden from your daily programmer via a nice API.
    - jimmyjazz14 16y ago
      Thats not entirely true, Websockets do initiate over http (by using the 'Upgrade' header so they can share port 80 with normal http traffic) but after the initialization handshake is finished the traffic no longer uses the http protocol.
pjscott 16y ago
Damn it! WebSockets are one of the nicest things in HTML5, and even for people using a compatibility layer like the excellent socket.io, things just seem to work better when the browser supports WebSockets natively. Of course, we're not going to get ubiquitous WebSocket support until Internet Explorer 10 becomes the new IE 6, which I doubt will happen for a long time. Even so, Firefox could make a big difference here. It would be nice.
- natmaster 16y ago
  From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire... "Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release."
kondro 16y ago
I think the WebSockets movement just died a little. It's already hard enough to write modern web-apps that work across a multitude of browsers either replicating features with crappy techniques in the older ones or being given the capability to degrade gracefully. Now, a feature that was expected on modern browsers now doesn't exist on some of them. Yes, I understand that there are security concerns, but it was concerns like this that lead browser makers to disable cross-domain JavaScript rather than implement a solution to do it securely. I hope WebSockets doesn't end up going the same way.
- Tichy 16y ago
  Maybe there is no simple solution.
  - kondro 16y ago
    For WebSockets? Maybe there isn't. It's not really the browsers fault necessarily, W3C takes many, many years to ratify standards so they go ahead an implement things themselves causing incompatibilities and, in the case of WebSockets, for them to provide features they now have to take away again. For cross-site scripting, there are many ways this could be enabled. Like the way Flash does it, for example, by placing a file at the root of a domain which specifies all the other domains it is allowed to talk to. Providing a manifest like this is likely the simplest solution to a problem that makes designing thick-clients quite annoying.
    - franck 16y ago
      Just for the sake of correctness, I want to point out that it's the IETF, not W3C, which is responsible for the WebSocket protocol.
      - kondro 16y ago
        I do apologize however, they don't move any faster. Has SIP even been ratified yet? :-p
wmf 16y ago
It's not clear that this security issue is real, but the WebSocket protocol is definitely going to change soon in a major way. I've been reading the the IETF HyBi list and the whole situation is pretty depressing.
- stanleydrew 16y ago
  Can you elaborate on that? I'm very interested in the progression of WebSocket and I wonder what's depressing you about the situation.
  - wmf 16y ago
    The last few months have been mostly occupied by arguments about hypothetical security holes — not in WebSocket itself but in other software that WebSocket might be used to exploit. During this time, virtually no actual work on the protocol seems to have been done. The recent paper (flawed as it is by ignoring framing) purporting to demonstrate such a security hole seemed to catalyze browser developers into a decision for a few days, but then the list collapsed into nitpicking and misunderstandings again. Meanwhile all of the alternatives that are being debated in the IETF are different from the WHATWG version that is deployed in some browsers today, so even if Mozilla did ship Firefox 4 with WebSocket, that version is already obsolete; we know there will be a replacement but we don't know exactly what it will be.
- tptacek 16y ago
  I'm not sure how one could interpret "we launched this attack using an advertising network on the general population of the Internet and found cases where connection routing fell under the control of our attacker" as "not a real issue". I see the political concern in your followup, but you didn't actually rebut the paper. It's an EKR-endorsed protocol security paper; my bet is, they're right. The problem statement certainly makes sense (browsers and proxies, both critical to Internet security, are not evolving the HTTP protocol in lock step).
  - wmf 16y ago
    The experiments in the paper didn't use WebSocket framing which likely would have prevented the attack from working. http://www.ietf.org/mail-archive/web/hybi/current/msg04750.html http://www.ietf.org/mail-archive/web/hybi/current/msg04750.h...
tjarratt 16y ago
I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, and a websocket connection could be started with an untrusted server? Anyone familiar with security and websockets? edit: I'm using websockets in a few projects (gracefully degrading to flash or XHR), and I'd like to know whether I should reevaluate webSockets. edit2: according to this mailing list, it's an issue with how proxies handle the HTTP Upgrade header. Awesome. http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html http://www.ietf.org/mail-archive/web/hybi/current/msg04744.h...
- FooBarWidget 16y ago
  Details are linked right there from the article.
- nitrogen 16y ago
  After reading eight or so e-mails from the thread you linked, it sounds like the vulnerability is in various proxies, not in WebSockets itself.
- oofo 16y ago
  Exactly the other way around, some man in the middle attacks get confused in the presence of websockets: "The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies" It's pretty weird that they consider this a problem with websockets.
  - tptacek 16y ago
    It's not an issue of "attributable fault". It's an issue of a reasonable protocol that doesn't work reliably on deployed infrastructure. Unlike, say, HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that tickles a bug in a widely deployed proxy can be catastrophic. Let's all be clear that the "fault" lies in crappy HTTP code deployed in middleboxes (and that includes mine), but pragmatic in understanding that that doesn't matter; browsers can't become roving exploits for proxy bugs just because a standard says so.
catshirt 16y ago
maybe there is a problem. this is not the solution. another checkmark on a long list of frustration with firefox 4.
- weavejester 16y ago
  What else can they do? If the websocket protocol is insecure, they need to wait until its fixed. They'll probably re-enable it in Firefox 4.0.1 or 4.0.2 with a fixed websocket implementation.
  - drdaeman 16y ago
    Stop spreading FUD. Websocket protocol is perfectly fine. What's insecure are broken proxies.
    - weavejester 16y ago
      Why take such an aggressive and accusatory tone? You don't have to reply with such vitriol. Secondly, I didn't actually say websockets were insecure; I said if they were, then Firefox is sensible not to include them. Third, even if the websocket protocol is secure in theory, if the majority of proxies don't correctly implement the upgrade header, then using websockets is insecure in practise.
jerf 16y ago
It still seems to me the problem is that they tried too hard to wrap the sockets into "the web". Just open a standard TCP socket to the web site's specified port and server. Layer me in some automatic SSL negotiation using the site's HTTPS cert (or something signed by it) if you want to win points. (Probably should mandate this, in fact, as it would block off most of the remaining "forging what site to connect to" issues; not unless you have the correct SSL info, in which case you've won anyhow.) I'm not sure what proxies are doing involved in sockets at all. I do not see what useful thing you can do with a proxy, except maybe flat-out block web sockets. They can't meaningfully cache, they can't meaningfully enforce policy except with the blindest, stupidest of approaches that should probably be in another layer anyhow. There's not enough structure in a raw socket connection to do anything with, what structure is there could and should be managed by your router. I'm sure there's some massive problem I'm missing here. (Though if it's "users can't use websockets through a proxy", frankly, I don't really see that as a problem that has a solution. By the time you fix up your "proxy" to allow "essentially arbitrary socket connections" what you've got there is a "router". If you're in an environment where you actually must use a proxy for some reason, you're in an environment that is probably going to ban arbitrary socket connections anyhow.) Now's your chance to enlighten me, I guess. I'm not trolling here, I do believe this, but I'm interested in the answers people give too. Maybe someone will convince me. (No joke.)
- nitrogen 16y ago
  Proxies are an issue because many corporations (and even ISPs) force all web traffic through a transparent proxy by redirecting outbound traffic to port 80 (and likely 8080 and 3128). HTTP proxies have long supported a way of establishing a raw TCP connection (though I'm unsure of the details), allowing things like corkscrew for using ssh behind a corporate firewall. As far as I know, these things use HTTP CONNECT. It seems there's another approach, HTTP Upgrade (which appears to be for switching to/from encrypted mode), which is used by WebSockets but breaks many proxies to the point of vulnerability to cache poisoning. I suppose if there are enough broken proxies out there that can't handle WebSockets, it's better not to take the blame from all those IE6 corporate types for breaking their Intranets.
- jimmyjazz14 16y ago
mike-cardwell 16y ago
The long polling technique that people currently use is good enough for the vast majority of cases, so I don't mind if WebSockets takes another few years to develop into something final. There's no need to rush out a protocol here. I'd rather they released something good.
DjDarkman 16y ago
> Unfortunately, this will not happen in time for the release date of Firefox 4. Then why release? Why release a product that is clearly not ready? Think about the developers for a second!
drdaeman 16y ago
What I don't get is why they're not disabling Java and Flash support too, then?

74 points by thehodge 16y ago

Yet another reason Chrome's rolling release auto updates are glorious. (When the protocol is fixed, Chrome users will all have it within a day or two; Firefox users, not so much) Additionally: Nochum's comment is concerning, if accurate: >This is gonna suck since the feature detection will be totally thrown off. >E.g.: >if (WebSocket in window) > ...

axod 16y ago
Relying on feature detection alone for WebSocket is a big mistake though. Websocket can fail for a number of reasons - proxies, stupid ISPs that interfere with HTTP traffic etc. In Mibbit, the code is something like this: if(WebSocket in window) { tryWebsocket(); window.setTimeout(function() { if (nothingHappened()) useComet() }, 5*1000); } else { useComet(); } Where comet in this case is keep alive long polling XHR.
- taitems 16y ago
  That's an interesting way of managing timeouts. Is the 5*1000 intended to just be a more readable way of specifying seconds?
  - mcav 16y ago
    I assume so. I do the same thing.
  - axod 16y ago
    Closure compiles it down to 5000 or 5E3 or whatever is smallest in my build process, so all the browser sees is '5e3'. I find 5*1000 most readable in my source code though.
- catechu 16y ago
  How can you check if nothing happened?
  - jacquesm 16y ago
    By changing some global variable in the callback and checking if it has changed in 'somethinghappened' (which only gets called after 5 seconds, giving the callback time enough to get called).
- bradgessler 16y ago
  Libraries like Socket.IO will detect if the connection can be made or not... so this point is moot. Feature detection first, connection detection second, then start degrading the transport until all options are exhausted.
  - axod 16y ago
    Sure. I was just explaining for those who prefer to write things like this themselves.
ergo98 16y ago
Yet another reason Chrome's rolling release auto updates are glorious. I like Chrome's silent updates, but the only real difference between it and Firefox is that Firefox informs the user that the update is being applied. Other than that, I'm not sure what you're referring to.
- drivebyacct2 16y ago
  Chrome updates much more frequently and I think you discount the amount that users ignore the update warnings.
  - jrockway 16y ago
    Of course, the people who know what Chrome is are not the people that ignore the warnings.
    - deleted 16y ago
      [deleted]
    - drivebyacct2 16y ago
      Couldn't disagree more. You'd be shocked at the number of CE/CS majors that ignore Firefox updates and complain about them. My mom uses Chrome on my parents' laptop and my dad uses Firefox. Guess which one is out of date :).
  - chime 16y ago
    Absolutely. I hadn't used one of my PCs for a couple of months and turned it on earlier today to find Chrome was two versions behind (7 vs 9).
jackvalentine 16y ago
Isn't Firefox 4 where Mozilla want to start using silent updates?
- drivebyacct2 16y ago
  Firefox is just playing catchup these days, isn't it? Don't get me wrong, that's fantastic. I think everyone benefits from auto-updates.
natmaster 16y ago
Not true. Firefox has auto updates, and will be pushing websockets the moment it gets fixed. Firefox also has the best record for turnout time on security fixes (many being released two days after report), so I doubt that will be slow. From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire... "Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release."
- drivebyacct2 16y ago
  I don't know what you're calling not true. I never suggested that Firefox wouldn't fix this in a x.1 revision. My point is more than 14% of Firefox users are using a version lower than current stable (and that's not counting who is in the [3.6.0, 3.6.12) range.

roschdal 16y ago

Scandalous.

tieTYT 16y ago

This article didn't provide any more information than the title. Can anyone fill the rest of us in. What are WebSockets and why should I care?

pjscott 16y ago
They're bidirectional sockets between the web browser and the server, essentially. They're handy whenever you want messages going back and forth between client and server without a bunch of reconnecting, or really ugly hacks. For example, apps like Etherpad or Apache Wave need to send messages for each editing operation (e.g. keystrokes), and it would really suck if they had to open a new HTTP connection for each one and do long-polling to receive from the server. Websockets make this sort of thing simply a matter of sending and receiving on a socket. Easy. You can fake them with something like Socket.IO, if you want the API and are willing to tolerate unpleasant performance on browsers that don't support it.
- tjarratt 16y ago
  What's the alternative for browsers that don't support it? If you want to gracefully degrade, then you may have to accept an underperforming solution. I'm using Socket.IO and while I'd rather not have to degrade to Flash for Firefox, if that's what I have to do to get support for Firefox users that haven't enabled websockets, I can live with it.
- mhitza 16y ago
  WebSockets are ugly hacks on their own. They use HTTP as well for the underlying channel of communication. The only difference is that with the WebSockets the ugliness is hidden from your daily programmer via a nice API.
  - jimmyjazz14 16y ago
    Thats not entirely true, Websockets do initiate over http (by using the 'Upgrade' header so they can share port 80 with normal http traffic) but after the initialization handshake is finished the traffic no longer uses the http protocol.

pjscott 16y ago

Damn it! WebSockets are one of the nicest things in HTML5, and even for people using a compatibility layer like the excellent socket.io, things just seem to work better when the browser supports WebSockets natively. Of course, we're not going to get ubiquitous WebSocket support until Internet Explorer 10 becomes the new IE 6, which I doubt will happen for a long time. Even so, Firefox could make a big difference here. It would be nice.

natmaster 16y ago
From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire... "Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox – even a minor update release."

kondro 16y ago

I think the WebSockets movement just died a little. It's already hard enough to write modern web-apps that work across a multitude of browsers either replicating features with crappy techniques in the older ones or being given the capability to degrade gracefully. Now, a feature that was expected on modern browsers now doesn't exist on some of them. Yes, I understand that there are security concerns, but it was concerns like this that lead browser makers to disable cross-domain JavaScript rather than implement a solution to do it securely. I hope WebSockets doesn't end up going the same way.

Tichy 16y ago
Maybe there is no simple solution.
- kondro 16y ago
  For WebSockets? Maybe there isn't. It's not really the browsers fault necessarily, W3C takes many, many years to ratify standards so they go ahead an implement things themselves causing incompatibilities and, in the case of WebSockets, for them to provide features they now have to take away again. For cross-site scripting, there are many ways this could be enabled. Like the way Flash does it, for example, by placing a file at the root of a domain which specifies all the other domains it is allowed to talk to. Providing a manifest like this is likely the simplest solution to a problem that makes designing thick-clients quite annoying.
  - franck 16y ago
    Just for the sake of correctness, I want to point out that it's the IETF, not W3C, which is responsible for the WebSocket protocol.
    - kondro 16y ago
      I do apologize however, they don't move any faster. Has SIP even been ratified yet? :-p

wmf 16y ago

It's not clear that this security issue is real, but the WebSocket protocol is definitely going to change soon in a major way. I've been reading the the IETF HyBi list and the whole situation is pretty depressing.

stanleydrew 16y ago
Can you elaborate on that? I'm very interested in the progression of WebSocket and I wonder what's depressing you about the situation.
- wmf 16y ago
  The last few months have been mostly occupied by arguments about hypothetical security holes — not in WebSocket itself but in other software that WebSocket might be used to exploit. During this time, virtually no actual work on the protocol seems to have been done. The recent paper (flawed as it is by ignoring framing) purporting to demonstrate such a security hole seemed to catalyze browser developers into a decision for a few days, but then the list collapsed into nitpicking and misunderstandings again. Meanwhile all of the alternatives that are being debated in the IETF are different from the WHATWG version that is deployed in some browsers today, so even if Mozilla did ship Firefox 4 with WebSocket, that version is already obsolete; we know there will be a replacement but we don't know exactly what it will be.
tptacek 16y ago
I'm not sure how one could interpret "we launched this attack using an advertising network on the general population of the Internet and found cases where connection routing fell under the control of our attacker" as "not a real issue". I see the political concern in your followup, but you didn't actually rebut the paper. It's an EKR-endorsed protocol security paper; my bet is, they're right. The problem statement certainly makes sense (browsers and proxies, both critical to Internet security, are not evolving the HTTP protocol in lock step).
- wmf 16y ago
  The experiments in the paper didn't use WebSocket framing which likely would have prevented the attack from working. http://www.ietf.org/mail-archive/web/hybi/current/msg04750.html http://www.ietf.org/mail-archive/web/hybi/current/msg04750.h...

tjarratt 16y ago

I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, and a websocket connection could be started with an untrusted server? Anyone familiar with security and websockets? edit: I'm using websockets in a few projects (gracefully degrading to flash or XHR), and I'd like to know whether I should reevaluate webSockets. edit2: according to this mailing list, it's an issue with how proxies handle the HTTP Upgrade header. Awesome. http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html http://www.ietf.org/mail-archive/web/hybi/current/msg04744.h...

FooBarWidget 16y ago
Details are linked right there from the article.
nitrogen 16y ago
After reading eight or so e-mails from the thread you linked, it sounds like the vulnerability is in various proxies, not in WebSockets itself.
oofo 16y ago
Exactly the other way around, some man in the middle attacks get confused in the presence of websockets: "The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies" It's pretty weird that they consider this a problem with websockets.
- tptacek 16y ago
  It's not an issue of "attributable fault". It's an issue of a reasonable protocol that doesn't work reliably on deployed infrastructure. Unlike, say, HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that tickles a bug in a widely deployed proxy can be catastrophic. Let's all be clear that the "fault" lies in crappy HTTP code deployed in middleboxes (and that includes mine), but pragmatic in understanding that that doesn't matter; browsers can't become roving exploits for proxy bugs just because a standard says so.

catshirt 16y ago

maybe there is a problem. this is not the solution. another checkmark on a long list of frustration with firefox 4.

weavejester 16y ago
What else can they do? If the websocket protocol is insecure, they need to wait until its fixed. They'll probably re-enable it in Firefox 4.0.1 or 4.0.2 with a fixed websocket implementation.
- drdaeman 16y ago
  Stop spreading FUD. Websocket protocol is perfectly fine. What's insecure are broken proxies.
  - weavejester 16y ago
    Why take such an aggressive and accusatory tone? You don't have to reply with such vitriol. Secondly, I didn't actually say websockets were insecure; I said if they were, then Firefox is sensible not to include them. Third, even if the websocket protocol is secure in theory, if the majority of proxies don't correctly implement the upgrade header, then using websockets is insecure in practise.

jerf 16y ago

It still seems to me the problem is that they tried too hard to wrap the sockets into "the web". Just open a standard TCP socket to the web site's specified port and server. Layer me in some automatic SSL negotiation using the site's HTTPS cert (or something signed by it) if you want to win points. (Probably should mandate this, in fact, as it would block off most of the remaining "forging what site to connect to" issues; not unless you have the correct SSL info, in which case you've won anyhow.) I'm not sure what proxies are doing involved in sockets at all. I do not see what useful thing you can do with a proxy, except maybe flat-out block web sockets. They can't meaningfully cache, they can't meaningfully enforce policy except with the blindest, stupidest of approaches that should probably be in another layer anyhow. There's not enough structure in a raw socket connection to do anything with, what structure is there could and should be managed by your router. I'm sure there's some massive problem I'm missing here. (Though if it's "users can't use websockets through a proxy", frankly, I don't really see that as a problem that has a solution. By the time you fix up your "proxy" to allow "essentially arbitrary socket connections" what you've got there is a "router". If you're in an environment where you actually must use a proxy for some reason, you're in an environment that is probably going to ban arbitrary socket connections anyhow.) Now's your chance to enlighten me, I guess. I'm not trolling here, I do believe this, but I'm interested in the answers people give too. Maybe someone will convince me. (No joke.)

nitrogen 16y ago
Proxies are an issue because many corporations (and even ISPs) force all web traffic through a transparent proxy by redirecting outbound traffic to port 80 (and likely 8080 and 3128). HTTP proxies have long supported a way of establishing a raw TCP connection (though I'm unsure of the details), allowing things like corkscrew for using ssh behind a corporate firewall. As far as I know, these things use HTTP CONNECT. It seems there's another approach, HTTP Upgrade (which appears to be for switching to/from encrypted mode), which is used by WebSockets but breaks many proxies to the point of vulnerability to cache poisoning. I suppose if there are enough broken proxies out there that can't handle WebSockets, it's better not to take the blame from all those IE6 corporate types for breaking their Intranets.
jimmyjazz14 16y ago

mike-cardwell 16y ago

The long polling technique that people currently use is good enough for the vast majority of cases, so I don't mind if WebSockets takes another few years to develop into something final. There's no need to rush out a protocol here. I'd rather they released something good.

DjDarkman 16y ago

> Unfortunately, this will not happen in time for the release date of Firefox 4. Then why release? Why release a product that is clearly not ready? Think about the developers for a second!

drdaeman 16y ago

What I don't get is why they're not disabling Java and Flash support too, then?