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):

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

Related links:

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

  1. Devin Says:

    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:

    @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.

  3. Robert Says:

    Wow! Serious lifesaver - the cache control headers worked for eliminating the bug in IE - though I’m also going to try the simpler url cacheing method - many many thanks!

  4. Carl Malartre Says:

    Hi, you will also see this bug with crossdomain.xml files:

    If you load a flash app on http and then you access any domain (even the same) with https, flash will try to download crossdomain.xml but it will fail.

    So the problem is really with IE, not flash.

    You have to let IE cache.

    So apply the same solution if you have problems using crossdomain.xml


  5. Jacob S. Says:

    brilliant! chewed on that one for a while! the headers fix it! Thanks!

  6. Nik Says:

    Nice one!!! Also safed my life!!

  7. Jermaine Says:

    Thomas: Can you make the source available for your test suite?

  8. Philippe Says:

    The SSL test suite is down. Can you turn it back on?

    Thanks a lot!

  9. Daniel Says:

    Thanks for this. I had the same problem with some webservice requests and also https crossdomain.xml
    I could have spent days on this!

  10. Brian A Says:

    Hi Thomas,

    Wanted to drop a note saying thanks for the tip - setting the headers worked beautifully.


  11. Chris Says:

    Hi Thomas,

    Thanks so much for the post. This problem was really killing me, didn’t realise that PHP session_start changed headers/cache settings.


  12. Mayckel Says:

    Hi Thomas, thank you very much!!!!

Leave a Reply