Comet is dead, long live websockets(armstrongonsoftware.blogspot.com)
armstrongonsoftware.blogspot.com
Comet is dead, long live websockets
http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
11 comments
It will probably be in all non-IE browsers soon enough, and then it becomes like border-radius. You get it if you have a real browser, otherwise some Flash fallback library will kick in.
It might get adopted quickly on a niche platform that relies heavily on webapps, and needs the efficiency because it is a relatively low powered device.
Like a phone.
Like a phone.
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/.
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/.
It seems that IE has been a consistent impediment to web based technologies for upwards of 10 years now.
This is patently untrue. In 1999, IE was the best available browser (Netscape would have been your other option).
It wasn't until Firefox in 2005 that a real alternative emerged (IMHO).
Sorry to be nitpicky, but it matters.
This is patently untrue. In 1999, IE was the best available browser (Netscape would have been your other option).
It wasn't until Firefox in 2005 that a real alternative emerged (IMHO).
Sorry to be nitpicky, but it matters.
Indeed. IE pushed many of the technologies that make today's stuff possible. Divs, usable Document Object Models, vector graphics, and XmlHttpRequest, to name a few.
I'd go so far as to say that it was 2008 before something genuinely better came along in the form of Chrome. Firefox did a good job of getting Microsoft to release IE7, but it was never compellingly better in the way that Chrome is.
I'd go so far as to say that it was 2008 before something genuinely better came along in the form of Chrome. Firefox did a good job of getting Microsoft to release IE7, but it was never compellingly better in the way that Chrome is.
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.
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.
Indeed. I can't believe the IE team hasn't implemented a standard whose draft specification is dated today. Why are they so fucking slow?
Websocket has been coming for about 12 months. Most of the spec was sorted out months and months ago.
Whether or not you are serious, indeed they should have something in the works for a standard whose draft specification is dated today.
I think the bigger issue is that Microsoft doesn't bother adhering to standards;
Or they make up their own standards when there are already perfectly good standards that provide the same functionality;
Or they implement part of a standard, but certain stuff is completely wrong, and when it is pointed out, they don't do anything about it.
And then they force you to conform their arbitrary non-standard stuff, because they can bully you with their 70% market share.
This isn't just about being slow, its about their course history of being slow AND maliciously protectionist AND incompetent.
And they should get ditched if they continue to behave in such a manner.
I think the bigger issue is that Microsoft doesn't bother adhering to standards;
Or they make up their own standards when there are already perfectly good standards that provide the same functionality;
Or they implement part of a standard, but certain stuff is completely wrong, and when it is pointed out, they don't do anything about it.
And then they force you to conform their arbitrary non-standard stuff, because they can bully you with their 70% market share.
This isn't just about being slow, its about their course history of being slow AND maliciously protectionist AND incompetent.
And they should get ditched if they continue to behave in such a manner.
Historically, Microsoft has put forth their own standards well before anybody else, only to see the official "Standard" be written differently by a 3rd party.
DOM, CSS, Box Model, Events, SVG, and a bunch of other things they did before anybody else (in a straightforward and reverse-engineerable way) were ignored by later groups who put together slightly incompatible "standards", some of which had no reference implementation. NN6, for example, was out for a full year before it implemented the W3C Events model that the Netscape team had proposed (which of course didn't exactly match the reference implementation that IE5 had in place 2 years earlier).
It's only recently that the Standards folks have managed to spec out things that the IE group hadn't done yet.
DOM, CSS, Box Model, Events, SVG, and a bunch of other things they did before anybody else (in a straightforward and reverse-engineerable way) were ignored by later groups who put together slightly incompatible "standards", some of which had no reference implementation. NN6, for example, was out for a full year before it implemented the W3C Events model that the Netscape team had proposed (which of course didn't exactly match the reference implementation that IE5 had in place 2 years earlier).
It's only recently that the Standards folks have managed to spec out things that the IE group hadn't done yet.
What makes you think this excuse to kill MSIE will work when 10 years of other excuses have failed?
Nobody seems to mention this but you can have HTML5 WebSockets on legacy browsers today via Orbited, http://orbited.org/.
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
I like how failing to implement a standard dated today makes it a legacy browser.
If I remember correctly, nothing goes into HTML5 unless it has already been implemented by at least two major vendors.
So what you're saying is that first there's a period of "proprietary extension" which we should shun because that's evil incarnate, then one day someone flips a switch and it becomes a standard and we mock the people left behind. [I don't meant that's actually what you write. A more figurative "you" with a generous interpretation of "anyone promoting HTML5 today].
For many years now, the rallying cry of the web has been "industry standards". But now, suddenly, we have redefined standard to be something like "Google said so". Sometimes Apple gets to say so.
Without apologizing for how bad IE may have been, I am uncomfortable with this turn of events for two reasons:
1. It smells like hypocrisy. A lot. 2. HTML5 isn't slated to actually be a standard until 2012. Basically requiring implementations to work to a proto-spec kind of defeats the purpose of having standards.
Let's say, just theoretically, that IE implements web sockets according to the draft. Then a day later, the Google employee who writes the draft changes it. How many hours until there's a HN post about how IE implements web sockets wrong?
For many years now, the rallying cry of the web has been "industry standards". But now, suddenly, we have redefined standard to be something like "Google said so". Sometimes Apple gets to say so.
Without apologizing for how bad IE may have been, I am uncomfortable with this turn of events for two reasons:
1. It smells like hypocrisy. A lot. 2. HTML5 isn't slated to actually be a standard until 2012. Basically requiring implementations to work to a proto-spec kind of defeats the purpose of having standards.
Let's say, just theoretically, that IE implements web sockets according to the draft. Then a day later, the Google employee who writes the draft changes it. How many hours until there's a HN post about how IE implements web sockets wrong?
I think there's a big difference between implementers working in the open to write standards and create test implementations and keep the public informed about the progress toward standardization - as Mozilla, Apple, Opera, and Microsoft are doing with HTML5 and related efforts - as opposed to developing in secret, and launching new features fully-formed into the wild with no chance for discussion and usually no adequate spec, as both Microsoft and Netscape did during the browser wars.
Agreed. Except for the part where nobody seems to consider these "test" implementations. I'm not so much critical of the process as the apparent developer community attitude/reaction/expectations to a work in progress.
Most of the reactions I see here and on Reddit are dozens of people saying, "Great, I can't use this until it's in IE." I'm not exactly seeing mainstream sites depending on these in-development technologies.
Not quite right. Nothing will be in HTML5 as a final recommendation unless it's in 2+ major implementations. There's plenty in the current drafts of HTML5 which has not yet been implemented.
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.
Orbited looks like an event-driven webserver, which is nice and all, but it doesn't magically give WebSocket functionality to legacy browsers.
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.
it doesnt magically give you websocket functionality, it lets you use the websocket api, then handles any fallback if thats needed.
As far as I can tell, the websocket pieces of Orbited were only in v0.5.0 and didn't make it into the latest releases. Am I wrong?
How is orbited different from BOSH+XMPP?
As far as I remember, BOSH is just built on long polling, and uses an XML-based syntax to define its protocol. The general idea is the same. The main differences: (0) perhaps most importantly it’s not immediately obvious how to send messages that aren’t XML-based over BOSH, because the protocol is defined in terms of XML payloads, meaning that if you have some protocol that wants to send arbitrary messages you’ll have to do something like putting your messages inside a CDATA block or escaping special characters, and your server-side code will need to come up with some way to do that, (1) Orbited’s design is a bit more general, accommodating transports other than long-polling, (2) Orbited has a bit less overhead, even in long polling mode, because it doesn't include a bunch of extra XML, (3) everything on the client end related to the particularities of Comet communication is designed to be treated as a black box by client-side JavaScript, which can just load Orbited’s JavaScript and then deal with its API – your in-browser code can roughly pretend it has a TCP socket, (4) Orbited operates as a proxy, speaking actual TCP out the back end, which means that your server code can just be written against a TCP socket and doesn’t need to implement anything special to communicate with browsers, or import any libraries, etc.
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)
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)
WebSockets have been capable of cross-origin communication since day one. (see: 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."
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-... 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-...
"The first three lines in each case are hard-coded" (referring to the origin)
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-... 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-...
"The first three lines in each case are hard-coded" (referring to the origin)
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/
> "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:
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/
> "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
[...]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
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
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.
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.
ok cool, if I stand corrected that would be awesome, cheers
The origin header represents the origin of the script initiating the request. The location is the address of the server. These can be different. By acknowledging the origin of the request, the server explicitly grants access to that origin.
This is similar to the origin model for cross-origin XHRs (http://www.w3.org/TR/access-control/#access-control-allow-or...).
This is similar to the origin model for cross-origin XHRs (http://www.w3.org/TR/access-control/#access-control-allow-or...).
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.
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.
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...
"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...
Except for the times when that HTTP header tells you don't need to download some huge amount of data...
Then it spends literally all the time parsing HTTP headers. :)
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".
FWIW, I believe the proper usage is "X is dead, long live X".
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.
1. too obvious handshake fingerprints for a firewall to block
2. No passive mode
3. Not supported by every browser.
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
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.
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?
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").