6 ms·

Comet is dead, long live websockets

109 points by mbrubeck 17y ago

daleharvey 17y ago
I love websockets, and have been waiting for them for a long time, however I am severely disappointed that there is no way to elevate permissions from the same origin "security" model, this is a huge limitation on the way towards purely client side javascript applications. html5 introduced crossdomain requests for xhr because it already proved to restrictive, and flash introduced crossdomain.xml. I wish w3c stopped pretending that in order to stop people from doing nasty stuff, you have to stop everyone else from doing anything (also looking at you, clipboard)
- franksalim 17y ago
  WebSockets have been capable of cross-origin communication since day one. (see: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#section-8.4 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...) "The |WebSocket-Origin| header is used in the Web Socket handshake. It is sent from the server to the client to confirm the origin of the script that opened the connection. This enables user agents to verify that the server is willing to serve the script that opened the connection."
  - daleharvey 17y ago
    yes but at nowhere in the specification does it say that either the client or server is allowed to modify the origin from the actual origin you are serving / being served from. This may be part of the specification that I am missing, but it seems to suggest that its using exactly the same origin model as original xhr, which is my complaint as http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-7 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... suggests "The Web Socket protocol uses the origin model used by Web browsers to restrict which Web pages can contact a Web Socket server when the Web Socket protocol is used from a Web page." and http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-4 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... "The first three lines in each case are hard-coded" (referring to the origin)
    - mbrubeck 17y ago
      The spec allows the server complete discretion to accept or reject cross-origin requests. Only the origin in the request (sent by the client) is defined in terms of the originating web page; it's left entirely up to the server to decide whether or not to allow requests from any given origin. The spec talks about the server being "willing" to respond to requests from different origins, and explicitly mentions that it may support multiple origins ("This is why the server has to send these strings: to confirm which origins and URLs the server is willing to service"). This is basically the same as the Cross-Origin Resource Sharing spec, another W3C spec supported by some current browsers: http://www.w3.org/TR/access-control/ http://www.w3.org/TR/access-control/ > "The first three lines in each case are hard-coded" (referring to the origin) No, the three hard-coded lines of each handshake part come before the origin headers: GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade [...] HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade [...]
      - daleharvey 17y ago
        the problem isnt the server, http servers right now can serve webpages to any client, its wether the client will allow the connection, as they dont with xhr from a guess at the fact they specifically say they use the existing same origin policy, they cant, but the confusion is cleared up with a simple test, I will check tomorrow
        mbrubeck 17y ago
        This is a way for servers to opt in and tell the client to allow cross-domain requests, just like crossdomain.xml or CORS. I haven't tried it myself with web sockets yet, but I've done some experiments with XHR+CORS (almost the same protocol, except for different names of the response headers) and it does work cross-origin on recent Gecko and WebKit browsers. UPDATE: Ran a quick test using the current Google Chrome beta for Linux and standalone.py from Google's mod_websocket, and successfully opened a cross-origin WebSocket connection, just as described in the spec. mod_websocket will authorize requests from any origin by default; there's a sample handler included that shows how to reject cross-origin requests on the server.
endtwist 17y ago
I find articles like this annoyingly premature. Sure, we're seeing the birth of a whole new way of communicating with the backend, which will only server to improve web apps in a positive manner. At the same time though, support for WebSockets in major browsers is woefully little, with only Chrome currently supporting it in an active "release," and (I believe) support available in the Firefox trunk for a later version. This still doesn't account for Safari or Internet Explorer, the latter being the biggest impediment to adoption. Additionally, I certainly don't think this is the beginning of the end for "AJAX" — not in the least. AJAX still has very strong grounds in pulling down data from the server that doesn't require some sort of long-running communication. Yes, let's get excited, but a little bit of a sanity check should be done if you're ready to call AJAX "dead" (or "dying").
- anonjon 17y ago
  I agree with you, but why can't this be used as an excuse to kill internet explorer? It seems that IE has been a consistent impediment to web based technologies for upwards of 10 years now. There have been so many other things that have been horribly crippled because 'internet explorer doesn't support it'. People are becoming more and more savvy from the standpoint of computer use, and putting up a redirect to install a new web browser... like Chrome or Firefox... is something the majority of people should be able to handle/understand. I'm tired of waiting 10 years to actually use the technology that we have /today/.
  - daleharvey 17y ago
    I think this is a point that a lot of people miss, everyone is quick to blame those big corporate it teams that wont upgrade browsers that its their fault. people dont upgrade unless they have a reason to, not because there is a better rendering engine or more plugins, by pulling your hair out and slowing yourself down to work on support for ie, you are also giving users a reason to not upgrade. but (IT wont let you install firefox because x only works on ie6) works both ways, if the rest of the web shoots forward with these new technologies, companies will catch up.
  - allertonm 17y ago
swannodette 17y ago
Nobody seems to mention this but you can have HTML5 WebSockets on legacy browsers today via Orbited, http://orbited.org/ http://orbited.org/.
- donw 17y ago
  Ok, I've never worked with Orbited. But I looked at the site, through the examples, and through the documentation, and I see nothing about being able to use WebSockets on, say, IE7 or Safari. Orbited looks like an event-driven webserver, which is nice and all, but it doesn't magically give WebSocket functionality to legacy browsers.
  - daleharvey 17y ago
    it doesnt magically give you websocket functionality, it lets you use the websocket api, then handles any fallback if thats needed.
  - jacobolus 17y ago
    Orbited functions as a proxy which lets you use a raw socket on your server end to communicate through the black-box Orbited in the middle to a JavaScript API that looks roughly like the WebSocket API. So as far as you as a developer are concerned, the code you have to write is about the same as if you were using WebSocket directly.
- mbrubeck 17y ago
  There are also Flash shims available on the client side, so you can use a WebSocket API that falls back to Flash on legacy browsers: http://github.com/gimite/web-socket-js http://github.com/gimite/web-socket-js
- tedunangst 17y ago
  I like how failing to implement a standard dated today makes it a legacy browser.
  - aristus 17y ago
joubert 17y ago
What's the chance this will get into IE?
- iamaleksey 17y ago
  It will, but not anytime soon.
FooBarWidget 17y ago
I agree that WebSockets is definitely the way forward and that stuff like Comet are merely hacks. However WebSockets is still premature: only Chrome supports it right now and even the server protocol isn't finalized yet. And the biggest hurdle is of course IE...
axod 17y ago
Lots of talk about IE here, but IE users aren't the ones using these new fangled realtime webapps. Ignore IE. They can stick with comet.
est 17y ago
Comet is not dead because websockets is: 1. too obvious handshake fingerprints for a firewall to block 2. No passive mode 3. Not supported by every browser.
- franksalim 17y ago
  WebSockets: 1. Can use TLS 2. The client always initiates the connection 3. Can be use the same API with a shim or comet underneath
mattmcknight 17y ago
"the current AJAX technology imposes an enormous overhead since virtually all the time in the server is spend parsing HTTP headers." Except for the times when that HTTP header tells you don't need to download some huge amount of data...
- mbrubeck 17y ago
  Then it spends literally all the time parsing HTTP headers. :)
tybris 17y ago
Good riddens. Comet was the painful reminder of how little browsers have developed over the last 10 years. It may be a little late, but who doesn't like sockets?
mr_justin 17y ago
Maybe when Microsoft implements Web Sockets in their browser 10 years from now, this might be applicable. FWIW, I believe the proper usage is "X is dead, long live X".
WesleyJohnson 17y ago
I'm currently working on a Google Chrome extension that communicates with a Web Service to do some data saving and loading. Since I'm targeting Chrome, Web Sockets seem compelling vs AJAX, however I have no idea on where to start implementing this server side. I'm using (puts on flame suit) IIS7. Are there any good tools or articles on getting Web Sockets running in IIS7. I'm a somewhat competent .NET developer, but I'm not a low level guy so something slightly above "For Dummies" would probably work best.

109 points by mbrubeck 17y ago

I love websockets, and have been waiting for them for a long time, however I am severely disappointed that there is no way to elevate permissions from the same origin "security" model, this is a huge limitation on the way towards purely client side javascript applications. html5 introduced crossdomain requests for xhr because it already proved to restrictive, and flash introduced crossdomain.xml. I wish w3c stopped pretending that in order to stop people from doing nasty stuff, you have to stop everyone else from doing anything (also looking at you, clipboard)

franksalim 17y ago
WebSockets have been capable of cross-origin communication since day one. (see: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#section-8.4 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...) "The |WebSocket-Origin| header is used in the Web Socket handshake. It is sent from the server to the client to confirm the origin of the script that opened the connection. This enables user agents to verify that the server is willing to serve the script that opened the connection."
- daleharvey 17y ago
  yes but at nowhere in the specification does it say that either the client or server is allowed to modify the origin from the actual origin you are serving / being served from. This may be part of the specification that I am missing, but it seems to suggest that its using exactly the same origin model as original xhr, which is my complaint as http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-7 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... suggests "The Web Socket protocol uses the origin model used by Web browsers to restrict which Web pages can contact a Web Socket server when the Web Socket protocol is used from a Web page." and http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-66#page-4 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... "The first three lines in each case are hard-coded" (referring to the origin)
  - mbrubeck 17y ago
    The spec allows the server complete discretion to accept or reject cross-origin requests. Only the origin in the request (sent by the client) is defined in terms of the originating web page; it's left entirely up to the server to decide whether or not to allow requests from any given origin. The spec talks about the server being "willing" to respond to requests from different origins, and explicitly mentions that it may support multiple origins ("This is why the server has to send these strings: to confirm which origins and URLs the server is willing to service"). This is basically the same as the Cross-Origin Resource Sharing spec, another W3C spec supported by some current browsers: http://www.w3.org/TR/access-control/ http://www.w3.org/TR/access-control/ > "The first three lines in each case are hard-coded" (referring to the origin) No, the three hard-coded lines of each handshake part come before the origin headers: GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade [...] HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade [...]
    - daleharvey 17y ago
      the problem isnt the server, http servers right now can serve webpages to any client, its wether the client will allow the connection, as they dont with xhr from a guess at the fact they specifically say they use the existing same origin policy, they cant, but the confusion is cleared up with a simple test, I will check tomorrow
      - mbrubeck 17y ago
        This is a way for servers to opt in and tell the client to allow cross-domain requests, just like crossdomain.xml or CORS. I haven't tried it myself with web sockets yet, but I've done some experiments with XHR+CORS (almost the same protocol, except for different names of the response headers) and it does work cross-origin on recent Gecko and WebKit browsers. UPDATE: Ran a quick test using the current Google Chrome beta for Linux and standalone.py from Google's mod_websocket, and successfully opened a cross-origin WebSocket connection, just as described in the spec. mod_websocket will authorize requests from any origin by default; there's a sample handler included that shows how to reject cross-origin requests on the server.

endtwist 17y ago

I find articles like this annoyingly premature. Sure, we're seeing the birth of a whole new way of communicating with the backend, which will only server to improve web apps in a positive manner. At the same time though, support for WebSockets in major browsers is woefully little, with only Chrome currently supporting it in an active "release," and (I believe) support available in the Firefox trunk for a later version. This still doesn't account for Safari or Internet Explorer, the latter being the biggest impediment to adoption. Additionally, I certainly don't think this is the beginning of the end for "AJAX" — not in the least. AJAX still has very strong grounds in pulling down data from the server that doesn't require some sort of long-running communication. Yes, let's get excited, but a little bit of a sanity check should be done if you're ready to call AJAX "dead" (or "dying").

anonjon 17y ago
I agree with you, but why can't this be used as an excuse to kill internet explorer? It seems that IE has been a consistent impediment to web based technologies for upwards of 10 years now. There have been so many other things that have been horribly crippled because 'internet explorer doesn't support it'. People are becoming more and more savvy from the standpoint of computer use, and putting up a redirect to install a new web browser... like Chrome or Firefox... is something the majority of people should be able to handle/understand. I'm tired of waiting 10 years to actually use the technology that we have /today/.
- daleharvey 17y ago
  I think this is a point that a lot of people miss, everyone is quick to blame those big corporate it teams that wont upgrade browsers that its their fault. people dont upgrade unless they have a reason to, not because there is a better rendering engine or more plugins, by pulling your hair out and slowing yourself down to work on support for ie, you are also giving users a reason to not upgrade. but (IT wont let you install firefox because x only works on ie6) works both ways, if the rest of the web shoots forward with these new technologies, companies will catch up.
- allertonm 17y ago

swannodette 17y ago

Nobody seems to mention this but you can have HTML5 WebSockets on legacy browsers today via Orbited, http://orbited.org/ http://orbited.org/.

donw 17y ago
Ok, I've never worked with Orbited. But I looked at the site, through the examples, and through the documentation, and I see nothing about being able to use WebSockets on, say, IE7 or Safari. Orbited looks like an event-driven webserver, which is nice and all, but it doesn't magically give WebSocket functionality to legacy browsers.
- daleharvey 17y ago
  it doesnt magically give you websocket functionality, it lets you use the websocket api, then handles any fallback if thats needed.
- jacobolus 17y ago
  Orbited functions as a proxy which lets you use a raw socket on your server end to communicate through the black-box Orbited in the middle to a JavaScript API that looks roughly like the WebSocket API. So as far as you as a developer are concerned, the code you have to write is about the same as if you were using WebSocket directly.
mbrubeck 17y ago
There are also Flash shims available on the client side, so you can use a WebSocket API that falls back to Flash on legacy browsers: http://github.com/gimite/web-socket-js http://github.com/gimite/web-socket-js
tedunangst 17y ago
I like how failing to implement a standard dated today makes it a legacy browser.
- aristus 17y ago

joubert 17y ago

What's the chance this will get into IE?

iamaleksey 17y ago
It will, but not anytime soon.

FooBarWidget 17y ago

I agree that WebSockets is definitely the way forward and that stuff like Comet are merely hacks. However WebSockets is still premature: only Chrome supports it right now and even the server protocol isn't finalized yet. And the biggest hurdle is of course IE...

axod 17y ago

Lots of talk about IE here, but IE users aren't the ones using these new fangled realtime webapps. Ignore IE. They can stick with comet.

est 17y ago

Comet is not dead because websockets is: 1. too obvious handshake fingerprints for a firewall to block 2. No passive mode 3. Not supported by every browser.

franksalim 17y ago
WebSockets: 1. Can use TLS 2. The client always initiates the connection 3. Can be use the same API with a shim or comet underneath

mattmcknight 17y ago

"the current AJAX technology imposes an enormous overhead since virtually all the time in the server is spend parsing HTTP headers." Except for the times when that HTTP header tells you don't need to download some huge amount of data...

mbrubeck 17y ago
Then it spends literally all the time parsing HTTP headers. :)

tybris 17y ago

Good riddens. Comet was the painful reminder of how little browsers have developed over the last 10 years. It may be a little late, but who doesn't like sockets?

mr_justin 17y ago

Maybe when Microsoft implements Web Sockets in their browser 10 years from now, this might be applicable. FWIW, I believe the proper usage is "X is dead, long live X".

WesleyJohnson 17y ago

I'm currently working on a Google Chrome extension that communicates with a Web Service to do some data saving and loading. Since I'm targeting Chrome, Web Sockets seem compelling vs AJAX, however I have no idea on where to start implementing this server side. I'm using (puts on flame suit) IIS7. Are there any good tools or articles on getting Web Sockets running in IIS7. I'm a somewhat competent .NET developer, but I'm not a low level guy so something slightly above "For Dummies" would probably work best.