[Sign up][Lost password?]

Event Streaming to Web Browsers

, , , , , , , , , , , ,

One cool feature we added to Opera 9 is Server-Sent Events from the WHATWG Web Applications 1.0 specification. Using SSE you can push DOM events continously from your web server to the visitor's browser. This creates a lot of exciting opportunities for web application authors.

Traditionally, when building an Ajax application, the browser continually polls the server, sending requests to the server, asking to get data back, making new HTTP requests for every single poll, putting more strain on the server than needed.

The event streaming approach instead opens a persistent connection to the server, sending data to the client when new information is available, eliminating the need for continuous polling. This method for doing remoting offers a tremendous advantage, since the server no longer has to handle the overhead associated with clients asking for new data. Instead, the server simply sends back data every connected client when appropriate, thus reducing the load on the server, with the added advantage of offering instant feedback to the user.

Opera Web Chat

Opera Web Chat Screenshot To provide you with a starting point on how to build your own event streaming application, we have built Opera Web Chat. This is a web based chatroom offering some of the features from the built in to the Opera IRC client. Currently the chat only offers one single chatroom. (A screenshot is available here)

Keep in mind that it is an experimental service, which means it may not always be available for use.

How to use Server-Sent Events

To use Server-Sent Events in a web application, add an <event-source> element to the document, with a src attribute pointing to a event source URL. This URL should provide a persistent HTTP connection that sends a data stream containing the events. The connection must use the content type application/x-dom-event-stream.

It is possible to send events with any name, and specify the properties of the event object. Opera 9.01 only supports the data property of the event, so this is what we are going to use in these examples.

The server side event source writes the events whenever they occur, and sends them over HTTP to the client. This is a basic example of event data. This is more thoroughly explained in the specification.

Event: server-time
data: [time on the server]

Event: the-answer
data: 42

This will send two events to the browser, and it's possible to catch them as DOM events. The following JavaScript example listens for the "server-time" event, and alerts the content.

        .addEventListener("server-time", eventHandler, false);

function eventHandler(event)
    // Alert time sent by the server

This is a very simple Python CGI example which sends a new event every 3 seconds. Every event is named "server-time", and sends an event with the data property set to the current time of the server in seconds.

Keep in mind that when a CGI script outputs data, there is no guarantee that it is sent immediately. There are often caching mechanisms and so on in place. For this reason it may be necessary to explicitly flush the output.

Here is the example code written in python.

import sys
import time
print "Content-Type: application/x-dom-event-stream\n\n"

while True:
    print "Event: server-time"
    print "data: %f\n" % (time.time(),)

The same example written in PHP:

header("Content-Type: application/x-dom-event-stream");
while(true) {
    echo "Event: server-time\n";
    $time = time();
    echo "data: $time\n";
    echo "\n";


In addition to the chat application we made, there are lots of different applications that can be made with Server-Sent Events. For instance games or instant messaging clients, such as MSN Messenger, Jabber or AIM. You could also build stock and news tickers, status and log file monitors, or anyhing you can come up with.

What will you build?

Moving and resizing widgetsWidget Web Chats


This is so great, I was looking for this for a widget that I'm working on.

I still can't make the chat sample to work.

By Guille, # 1. September 2006, 16:12:51

graste writes:

Awesome. How about an IMAP widget? Perhaps I should write to my email hosters, that they should think about that for the future. :wink:

By anonymous user, # 1. September 2006, 16:23:25

This opens up a whole new level of web interaction! But since it's Opera only, I guess it is mostly confined to widgets ATM :smile:

Let's see when the first two player action widget debuts!

By GreyWyvern, # 1. September 2006, 16:26:29

Milo writes:

How does this reduce server load? Now the server has to manage many more open connections at once. I think any server that uses this will have a much harder time scaling once demand increases.

By anonymous user, # 1. September 2006, 17:19:00

@Milo: Ofcourse it's crazy to have thousands of PHP processes on Apache server, but you can handle large number of connections with a dedicated server and save a lot of bandwidth (TCP/IP alone doesn't generate any traffic when there aren't any changes, unlike regular AJAX requests which pump packets all the time).

By porneL, # 1. September 2006, 18:28:10

Jay writes:

Is there support for the x-dom-event-stream type in Opera Mobile or Mini?

By anonymous user, # 1. September 2006, 19:40:57

WebApplications speaks seldom, but to the point :smile: Tried the demo, quite impressive

By velmu, # 1. September 2006, 20:42:02

The OperaWatch article was also on the frontpage of digg.com. I've heard a lot of positive things about this. But I also have to say I've never seen so much crashes of Opera on one day.

This feature is just new to the general public, so there could still be bugs, but other than that, it's just a great new feature :D

By remcolanting, # 1. September 2006, 22:32:30

It's cool, but the chat demo crashes my Opera (9.01) every time I write something.

By grafio, # 1. September 2006, 22:36:10

I had no crashes or problems... I'm still using 8515 though.

By piper_noiter, # 1. September 2006, 22:50:23

Eric Blade writes:

I would guess that this would be close to a final step of eliminating the operating system as a platform for many types of applications, and making them web-based. Might even be cooler than Java should have been.

I could really use some more specific documentation and examples, though. How about source for the chat program?

By anonymous user, # 2. September 2006, 03:52:49

Anonymous writes:

What's new? If you keep the connection open, you can do all that with plain javascript.

By anonymous user, # 2. September 2006, 05:59:10

Your PHP code is very ugly.

header("Content-Type: application/x-dom-event-stream");

for (;;)
echo "Event: server-time\n",
'data: ', time(), "\n\n";


"ob_flush" should be use only if "ob_start" was used.

By bolk, # 2. September 2006, 07:29:26

What about Firefox, does it come to support this? How about IE7?

By Jazmo, # 2. September 2006, 08:15:19

THis is awesome, even on My PIII , 64kbs connection the chat app opened in seconds , and is running fast and smooth!!
very very cool!!

By chesss, # 2. September 2006, 08:20:46

Anonymous writes:

For support of WHATWG in Firefox, check http://wiki.mozilla.org/XULP:riority_List#Priority_6

By anonymous user, # 2. September 2006, 09:21:10

fforw writes:


Firefox has been supporting something similar using XMLHttpRequest and multipart/x-mixed-replace, but that is far from being as clean as this.
(see e.g. http://www.subbu.org/weblogs/main/2006/04/dissecting_ajax_1.html#pushDemo )

By anonymous user, # 2. September 2006, 09:23:11

Anonymous writes:

HTML client example please

By anonymous user, # 2. September 2006, 11:04:57

If anyone is getting crashes when trying the chat demo, please report them:


By haavard, # 2. September 2006, 12:35:08

Ned Baldessin writes:

So I gather this is a proper standardized implementation of what is currently being called "commet", am I correct?


By anonymous user, # 2. September 2006, 14:54:10

Kimberley Burchett writes:

Why does Opera only support the "data" property of events? I work on a product designed to work with generic event streams, and this limitation seems quite unfortunate.

I think the SSE spec should restrict itself to generic event streams, and be agnostic about how the receiver of an event should interpret it. The fact that the spec has special support for things like "Bubbles" seems like a mistake to me. It's like making the HTML spec have special support for Flash.

I have the feeling that it's this over-reaching of the spec that makes the Opera folks think it's reasonable to only support "data" properties. Supporting things like Bubbles would make the implementation more difficult. I'd rather see Opera deal with this by just ignoring the special semantics than by refusing to support event streams with more information.

By anonymous user, # 3. September 2006, 02:55:30

@Kimberley: The implementation should still be considered "experimental", and part of an emerging specification, which is why we do not have a full implementation yet.

If you have comments in specific about the specification, they are best addressed on the WHATWG mailing list.

By virtuelvis, # 3. September 2006, 18:00:21

I think that idea is very good and necessary in this moment for better the Opera browser, fix some detailes.

By Salsero_Nash, # 4. September 2006, 03:47:40

"Let's see when the first two player action widget debuts!"

Had source code for a two player widget for a while... Haven't written the networking part for it though but I have something to base that stuff on. Not very "action" though... a board game.

I'm having trouble getting this stuff running.. might be a problem in my PHP or Apache configuration.

By zomg, # 4. September 2006, 16:57:46

Svenner80 writes:

Server-Sent Events are a great feature indeed! We've been playing around with this and even though it's still a bit Beta (Opera crashes from time to time when multiple browser instances get opened using server streaming) this will probably get stable over time.

What are the policies maintaining connections? E.g. when I change pages (including complete page refresh and reload) and have the same <event-source> element pointing to the same URI, will the browser open a new connection to the server for this.

Or would one have to use something like frames (quite ugly) to prevent the reload of the html parts where <event-source> is included?

By anonymous user, # 7. September 2006, 07:42:13

sindhu writes:

all this sounds great (although ive no idea how you guys do it) but as a consumer :smile: of opera. think it should be good if this server side events gives it an edge over other exisiting browsers.

By anonymous user, # 7. September 2006, 17:22:40

Anonymous writes:

Something that would definitely be addressed would be how to deal with this on a server implementation. I would definitely love to take advantage of this for a web game that I am developing, so we can easily support real-time operations, and I can see it gracefully failing for non-Opera browsers (though I bet it'd be 5 years before IE8 comes up with half-arsed support for it, maybe Mozilla might have it in the next year or so) ... but it's going to just choke a server if you're dealing with it with a web server.

Having a seperate open persistent apache thread running perl or php for every indivdual user connected could bring even high end computers to their knees.

You'd be better off writing some sort of application that ran in a single thread, and used select() to deal with incoming connections, and I wonder if PHP could actually even deal with this. (Does PHP have the ability to be used for more robust socket applications? Does PHP have the ability to open a port, listen for many connections, and serve them?)

By anonymous user, # 11. September 2006, 08:11:27

In Anyterm (http://anyterm.org/ - site has demos, not sure if they work with Opera!) I have achieved something much like this with plain old HTTP. Basically, the client makes an HTTP request, and the server doesn't send a response until it has some data to send. When it gets the response the client makes another request, which should be over the same persistent HTTP connection. The server has to send an empty response eventually if there is no data so that the client doesn't time out, but it's only necessary to do this perhaps every 30 seconds; if it was polling it would need to be 100 times as fast to get the same level of responsiveness.

This new stuff is certainly interesting, and it would have been great if it had existed from day 1. But it will be a long long time before it is widespread in browsers and for now we can get the same effect using regular HTTP.

By endecotp, # 12. September 2006, 20:14:03

I like being able to chat. It's much more personal than "forums". I managed to log in, but there's no button to log out. I presume that it didn't ask me for a password because I was already logged in to Opera Community. If that is not the case, how secure is it?

By mezzomama, # 19. September 2006, 07:10:18

mezzomama: The SSE chat is a proof-of-concept demo chat that doesn't use/require authentication[1], so your only identification is the nickname you choose.

However: It is entirely possible to build secure applications with authentication using this technology.

By virtuelvis, # 21. September 2006, 16:59:25

@anonymous user, # 11. September 2006, 10:11:27

I've written a stand-alone server for SSE with Python. So far it's been performing quite nicely on my 333mhz/64mb ram server box

You can find it from this page with some details on how to use it

By zomg, # 24. September 2006, 22:30:01

Write a comment

You must be logged in to write a comment. If you're not a registered member, please sign up.


My page is hosted by Opera Community. When you sign up you get access to post comments on my page aswell as all other pages hosted on my.opera.com. You also get access to free services provided by Opera Community, such as blogs and photo albums.

lock iconThe data you provide during the registration is safe with us, we do not share it with third parties.

All fields are required:


By clicking 'I agree to the terms', you warrant that you will not upload files that are obscene, vulgar, sexually-orientated, hateful, threatening, or otherwise violative of any laws. The owners of Opera community have the right to remove files and close any account for any reason.