In an InfoWorld article, from last week, a mention of using streaming HTTP for advanced Web-based applications was made. There was barely any explanation of the technology and I imagine that some people don’t know how it works. I figured that I could pull together a couple examples to show people. The basic concept is such:
You create a CGI application (or a complete web server, dishing out dynamic content) which continually pushes mini-updates to a user’s browser. To acheive this, the connection between the user’s browser and the server must never be closed. For example, the normal HTTP process is: Request -> Data is Read From File -> Data is Sent to Browser -> Connection is Closed. One new way of doing it could be: Request -> (1) DB is checked for Updates -> Data is Sent to Browser -> Goto (1). Notice that the connection is never closed – this is important. Now, the ‘chunks’ of data that are being sent to the browser could exist in the form of Javascript chunks or even XML. Sounds simple enough, but the hassles are just beginning.
- The most common way for streaming these items is through an IFrame which contains a page that is forever loading – which is seemingly ok, since it’s not the main user page. However, all major browsers will state that the page is still loading as long as the user is on the page. In my opinion, this is a rather large usability issue. Also, if a user does hit the stop button, all of the streaming content will be killed – unbeknownst to them.
- The only way to get around this issue is to use a server push method using a multipart/x-mixed-replace header, which only works in Mozilla-based browsers. You’d think that something that’s a part of HTTP would be implemented across the board in all browsers, but not so.
- Now, if you want to circumvent the use of an IFRAME, you could try using the multipart trick with XMLHTTPRequest (with server side) – which is cool, no doubt, but again doesn’t work in non-Mozilla-based browsers.
- Oh, and while you’re testing – don’t open two streaming pages up in Firefox – it won’t work. Firefox thinks that the first page that you open is still loading and, therefore, should wait until the page is done loading to load the other one too.
- And if you’re running this streaming app in a CGI application that’s behind Apache, be sure that you have GZIP compression turned off – if you don’t, Apache will wait until your entire page loads, in order to try compressing it, before sending it to the browser.
A couple points to consider:
- ‘Typical’ AJAX appliations utilize XMLHTTPRequest doing single requests/updates. The next wave of web applications are going to have more streaming components included. This is going to be an essential portion of any new web application coming out.
- There is very very little aggregated knowledge on the concept of streaming http, which makes development of this technology very hard.
- This is all ironic because this technology has been around for much longer then the use of XMLHTTPRequest and yet is is used less then this ‘newer’ technology. Some of this can bee seen in a post by Matt Haughey about KnowNow using Streaming HTTP.
So, anyway: There needs to be more documentation and more use of Streaming HTTP / Server Push technology – if you don’t use it in your applications, someone else will, I can guarantee it.
Brad Neuberg (June 5, 2005 at 11:18 pm)
So, what’s the solution? You go over what doesn’t work, but what does? What is KnowNow, mod_pubsub, and Pushlets doing under the hood?
Jordan Sissel (June 6, 2005 at 1:16 am)
Re above, Pushlets appears to support multiple methods of throwing data at the browser (polling, streaming, etc)
This is very cool stuff, it’s about time someone actually started using http 1.1’s streaming for something useful.
Scott Rubin (June 6, 2005 at 8:03 am)
Games. Somebody needs to make games with this stuff. There used to be a lot of javascript games that were turn-based and reloaded after everything you did. And they usually used form elements for the interface. Now of course flash and java have cornered the in-browser game market. But if we get SVG or some such standard in all the browsers and use streaming HTTP we can definitely make real time games that work in any major modern browser without plugins. Definitely good. Surprised it isn’t done yet.
John Resig (June 6, 2005 at 8:27 am)
Brad: Theoretically, what I mentioned above should work, it’s just a crazy hassle getting it to the point where it’s usable, which is a shame. KnowNow, mod_pubsub, and pushlets all used the ‘keep a never-closing connection open with the browser’ technique where you just keep a constantly-open connection to the server which will forever push chunks of Javascript to the browser.
What makes what they’re doing especially confusing is just how simple their code is – they don’t appear to be sending any additional headers or anything. This confuses me because I try pieces of code that are equally as simple, but to no avail. I’m not entirely sure if it’s an issue with the servers that I’m using, the code that I’m writing, the browsers that I’m using, or what. There are too many unknown variables occuring. Man, AJAX development is a cakewalk compared to this.
John Resig (June 6, 2005 at 11:19 am)
Scott: It seems like some sort of an MMORPG would be very interesting to implement using this technology, or maybe even some adaptation of an old MUD to be used through a browser. Let me know if you find any examples if someone does use it.
Ben (June 29, 2005 at 4:44 pm)
Been doing this for a while, doing online chat systems for social networks. I’ve got nice implementations in Python and Ruby.
Jan Bartel (November 11, 2005 at 7:57 am)
Jetty – http://jetty.mortbay.org/jetty6 – has introduced support for server side push via a Continuations mechanism. Greg Wilkins blogged about it on http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html. Basically, the mechanism allows a client to keep an outstanding request with server, to which the server only responds when there is new data. The cool thing is that whilst the server is waiting for data, it frees the thread servicing the request, meaning that AJAX apps can be easily scaled, and don’t require any messy client-side javascript to backoff timed polls etc etc.
Orestis (September 21, 2007 at 3:58 pm)
Cool…
Jacob Rus (October 30, 2007 at 6:37 pm)
I’m in complete agreement that we need better documentation of HTTP push (now called “Cometâ€) techniques, and more developers should use it. That’s why I’m helping out with the Orbited project, which has implemented Comet techniques which work well, with no untoward side effects, in every modern browser. Michael Carter recently wrote a fascinating article about one-such technique, which uses the “htmlfile†ActiveX object to provide streaming support in IE. I’ve also spent a bit of time spiffing up the Comet article at Wikipedia, which by the time I’m through with it should hopefully provide a good summary of every usable Comet transport, and a better discussion of server-side concerns as well.
Dylan Schiemann (November 5, 2007 at 4:01 pm)
John, as Jacob mentioned by linking to Michael Carter’s article, this is exactly the type of stuff we’re hoping to accomplish with Comet Daily, which we quietly launched last night.