« Red Bull Flugtag Flight Lab - Mini Hangar Widget
Internship at Less Rain Berlin office »


Flash loading and browser cache test-suite

July 10th, 2008 by Thomas

As a little homage to our most popular and seemingly helpful blog post about the Nasty XML load bug in Internet Explorer I created an app that tests the caching behavior of the browser it’s running in.

To recap - Loading XML files in Flash over an SSL Connection in Internet Explorer fails if the “Pragma: no-cache” or “Cache-Control: no-cache” HTTP headers are set in the server’s response.
In AS2 the loading failed silently, in AS3 we at least get an IO Error #2032, which has been discussed several times (see below)

If you want to keep the browser from caching your dynamic content you’ll have to use other means.
Judging from my tests, the best headers to prevent caching without causing errors in IE are: “Cache-Control: no-store” and/or “Expires: Thu, 01 Jan 1970 01:00:00 GMT”.

You can access the test suite here:

Set the headers that you’d like the server-script to return and find out what happens when the same request is sent twice after each other.
Use the Live HTTP Headers Plugin for Firefox if you’d like to see what the server actually returns.

Other interesting insights

  • The problem still exists in Internet Explorer 7! Don’t know about Vista…
  • Here it’s suggested that “Cache-Control: must-revalidate” and “Cache-Control: max-age=0″ also work. While that’s true in the sense that they don’t cause an error IE, they don’t seem to prevent caching 100% - there is a timeout.
  • “Pragma: no-cache” causes the error in IE, but doesn’t actually prevent it from caching at all when it’s set on a non-ssh connection.
  • Firefox internally sets the expiry date of script files to the past - so unless you set the “Expires” header to the future it’ll never cache the content.
  • Safari and Firefox change their caching behavior when the “Last Modified” header is set. If it’s in the past they seem to be happy to cache the file for you.

PHP sessions

Note that in PHP, as soon as you use sessions with session_start() the no-cache headers are added automatically. You’ll have to replace those headers or turn the default behavior off in php.ini. To replace the headers (found in the comments of the original post, see also the session-cache-limiter function and comments):

session_cache_limiter(’public’);
session_start();
header (”Cache-Control: cache, must-revalidate”);
// or if you still want to prevent caching
header (”Cache-Control: no-store”);
header (”Pragma: public”);

Related links:

This entry was posted on Thursday, July 10th, 2008 at 1:57 pm and is filed under AS2, AS3, Bugs, Cross-browser, Flash, HTML, PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Flash loading and browser cache test-suite”

  1. Devin Says:
    August 16th, 2008 at 9:49 pm

    I have also ran into this problem in an application I have worked on. Since using headers works inconstantly. I find just adding a timestamp to the url is the easy way of dealing with this problem.
    (I notice you do not mention that in these two blogs, but it is in the Browser cache test-suite). For those who do not know what I am talking about here is a quick run down.

    What you can do is add a timestamp onto your url in the query string.
    Ex: var url:String = “www.google.com?timestamp=” + new Date().getTime();

    This will add the number of milliseconds since January 1, 1970, to the end of the query string.

    When IE caches any file it caches the query string part also. So the next time the url is called the timestamp is different so IE treats it like a brand new file. This is also the only way of doing things if you do not have control of the headers on the dynamic XML.

  2. Thomas Says:
    August 18th, 2008 at 5:35 pm

    @Devin: thanks for adding your explanation and completing the post. It’s a valid and practical solution to prevent caching, especially if you don’t have access to the back-end. However if you want to leave cache control in the hands of the back-end and your browser you have to be be aware of the behavior of cache control headers - that’s what I dedicated this post to.

    I think it’s the cleaner and more flexible solution to control caching in the back-end, without creating “hacks” in the front-end. Imagine data services that serve different front-ends- you’ll have to tell every developer to append timestamps, where your back-end should be responsible of defining when data ought to be be refreshed.

Leave a Reply