

Comet is dead, long live websockets - mbrubeck
http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html

======
endtwist
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
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/.

~~~
tedunangst
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?

~~~
anonjon
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.

~~~
jasonkester
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.

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

~~~
donw
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.

~~~
jacobolus
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.

------
daleharvey
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
WebSockets have been capable of cross-origin communication since day one.
(see: [http://tools.ietf.org/html/draft-hixie-
thewebsocketprotocol-...](http://tools.ietf.org/html/draft-hixie-
thewebsocketprotocol-66#section-8.4)) _"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
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-...](http://tools.ietf.org/html/draft-hixie-
thewebsocketprotocol-66#page-7) 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-...](http://tools.ietf.org/html/draft-hixie-
thewebsocketprotocol-66#page-4)

"The first three lines in each case are hard-coded" (referring to the origin)

~~~
mbrubeck
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:

    
    
            GET /demo HTTP/1.1
            Upgrade: WebSocket
            Connection: Upgrade
            [...]
    
            HTTP/1.1 101 Web Socket Protocol Handshake
            Upgrade: WebSocket
            Connection: Upgrade
            [...]

~~~
daleharvey
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
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.

~~~
daleharvey
ok cool, if I stand corrected that would be awesome, cheers

------
WesleyJohnson
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.

------
FooBarWidget
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...

------
mattmcknight
"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
Then it spends _literally_ all the time parsing HTTP headers. :)

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

------
est
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
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

------
axod
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.

------
joubert
What's the chance this will get into IE?

~~~
iamaleksey
It will, but not anytime soon.

------
tybris
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?

