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

       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)


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.


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.

11 Responses to “The forever-frame technique”

  1. Comet Daily » Blog Archive » The dreaded 2-connection limit Says:

    [...] 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 [...]

  2. Comet Daily » Blog Archive » The Future of Comet: Part 1, Comet Today Says:

    [...] 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 [...]

  3. Comet Daily » Blog Archive » Latency: Long Polling vs Forever Frame Says:

    [...] 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 [...]

  4. Comet Daily » Blog Archive » Easing into Comet Says:

    [...] 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 [...]

  5. Comet Daily » Blog Archive » Coming Soon: Comet on AIR? Says:

    [...] 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 [...]

  6. Comet Daily » Blog Archive » Reverse Ajax with Google Gears? Says:

    [...] 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 [...]

  7. Comet Daily » Blog Archive » Comet Gazing: Frustrations Says:

    [...] couple of years ago, the frustrations with the forever-frame technique were rather annoying: incompatibility or crashing with Firebug in early releases, tracking down [...]

  8. Antonio Says:


    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,

  9. prajwala Says:


    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.

  10. Comet Daily » Blog Archive » Comet in Newspapers: The Spanish Lottery Experiment Says:

    [...] 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 [...]

  11. What came before WebSockets? | Phil Leggetter - Real-Time Web Software and Technology Evangelist Says:

    [...] 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 [...]

Copyright 2015 Comet Daily, LLC. All Rights Reserved