The forever-frame technique
by Dylan SchiemannNovember 5th, 2007
The forever-frame Comet technique is a true push implementation that is not based on polling, the XMLHttpRequest, or setting a dynamic script source. Instead, features of HTTP 1.1 originally intended for transfer and incremental rendering of very large documents are put to use to incrementally deliver data through an HTML iframe element.
This technique is very low-latency because it avoids HTTP and TCP/IP set-up and tear-down by reusing a single long-lived connection.
Chunked Encoding
Chunked Encoding is the feature in the HTTP 1.1 specification allowing a server to start sending a response before knowing its total length. This allows the server to break a complete response into smaller “chunks”, sending them in series. Responses are easy to identify because their header contains “Transfer-Encoding: chunked”. A specification for a message is as follows:
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*(”0″) [ chunk-extension ] CRLF
chunk-extension= *( “;” chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
Iframe
In typical Comet server implementations such as mod_pubsub, KnowNow, and Lightstreamer, a hidden iframe element is opened in the browser after page load, establishing a long-lived connection inside the hidden iframe. It is not supported in the current version of the Cometd client found in Dojo 1.0, but it will return in the near future. That said, it’s simply a matter of using the DOM to create a hidden iframe, and setting the source with the necessary parameters to communicate with your Comet server.
Incremental rendering and flushing
Browsers incrementally render chunked encoded documents after each chunk is rendered. Each chunk is wrapped in a script block, and executed with a function call in the Comet client library living in the parent document. Not every browser behaves well. For example, Internet Explorer requires a rendering element such as a <br /> tag, and Safari requires 1KB of data (usually sent in the form of whitespace), to force incremental rendering. The major Comet toolkits provides these workarounds automatically. In order to avoid excessive peak memory usage, the DOM nodes added to the iframe are typically removed after they are rendered.
Summary
The forever-frame technique uses HTTP 1.1 chunked encoding to establish a single, long-lived HTTP connection in a hidden iframe. Data is pushed incrementally from the server to the client over this connection, and rendered incrementally by your web browser.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
November 11th, 2007 at 11:00 pm
[...] between a client and a web server, making things especially difficult for long-polling and the forever-frame technique, the two staple Comet techniques. Mozilla Firefox by default provides web applications with 8 [...]
December 11th, 2007 at 6:19 am
[...] HTML. These mechanisms, like other Comet “transports” such as htmlfile ActiveX objects, “forever frame” iframes, or XHR streaming, allow a browser to open a persistent connection to a server, and receive [...]
December 18th, 2007 at 12:31 am
[...] of the oft-cited advantages of forever frame over long polling is that it does not suffer from the 3x max latency issue. This is when an event [...]
February 5th, 2008 at 2:16 pm
[...] using a Comet framework can speed development, but I will focus on resource utilization. While a forever frame may be the highest performing approach for Comet, it is not necessarily the lowest cost. We will [...]
February 25th, 2008 at 8:26 pm
[...] so hopefully by this time next week we’ll be able to show off what’s possible. The forever-frame technique might be a challenge, but long-polling should be trivial. While developers will always have Flash [...]
April 11th, 2008 at 12:53 am
[...] other Google news, Dion Almaer writes about resumable uploads with Gears. Can anyone say forever-frame in reverse, by simulating a really large upload to keep a persistent client to server connection [...]
April 28th, 2008 at 9:14 am
[...] couple of years ago, the frustrations with the forever-frame technique were rather annoying: incompatibility or crashing with Firebug in early releases, tracking down [...]
March 5th, 2009 at 11:42 am
Hello,
I’m a newby to all this js, ajax, comet stuff.
I’ve found many articles about iframe and streaming, but neither examples nor good manuals.
We are developing an http streaming client/server. At the server side we use chunked transfer encoding for the responses, but at the client side we don’t know how to get the chunks.
What is the best practice? We need supoort for all browser and so we have been told that iframe is the best technique as xmlhttprequest don’t fires onreadystatechange event until the connection is closed.
Any help will be appreciated,
Antonio.
May 28th, 2009 at 4:52 am
Hi,
I implemented this iframe technique, but the browser status bar is showing loading. This is looking odd. How can I avoid showing loading on the browser status bar. I did not understand how to pass those header information, what are the values for the headers etc.. . Can I solve the browser status bar showing loading by providing those header information? If yes can you please provide me one example with the values of the headers.
December 22nd, 2009 at 9:53 pm
[...] know there are several non-Ajax techniques for Comet, like the forever page, forever frame or script tag long-polling. These techniques are not as clean as Ajax-based alternatives, so I will [...]
September 7th, 2011 at 10:55 pm
[...] superseded, due to Java Virtual machine inconsistencies, by a native browser technique known as forever frame where a long-lived HTTP connection is established to the server using a hidden frame. Data, usually [...]