Comments on: Flash loading and browser cache test-suite

By: Mayckel

Mayckel — Mon, 30 May 2011 08:18:57 +0000

Hi Thomas, thank you very much!!!!

By: Chris

Chris — Tue, 19 Oct 2010 04:20:44 +0000

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.

Thanks!!!

By: Brian A

Brian A — Mon, 11 Jan 2010 07:30:14 +0000

Hi Thomas,

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

Thanks.

By: Daniel

Daniel — Wed, 09 Dec 2009 16:58:40 +0000

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

By: Philippe

Philippe — Thu, 03 Sep 2009 18:30:46 +0000

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

Thanks a lot!

By: Jermaine

Jermaine — Tue, 18 Aug 2009 15:29:33 +0000

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

By: Nik

Nik — Mon, 08 Jun 2009 19:36:42 +0000

Nice one!!! Also safed my life!!

By: Jacob S.

Jacob S. — Sun, 31 May 2009 19:00:49 +0000

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

By: Carl Malartre

Carl Malartre — Fri, 29 May 2009 17:35:54 +0000

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.
http://support.microsoft.com/default.aspx?scid=kb;en-us;272359

You have to let IE cache.

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

Carl

By: Robert

Robert — Sat, 23 May 2009 07:07:15 +0000

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!

By: Thomas

Thomas — Mon, 18 Aug 2008 15:35:07 +0000

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

By: Devin

Devin — Sat, 16 Aug 2008 19:49:48 +0000

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.