flashembed addition of random query string to src variable is cache unfriendly Created Jun 13, 2009

It's there just because of caching issues. Sometimes IE fails to load the SWF file alltogether without this random string. I have experienced this myself. This random string simply cured the situation.

If you really want to have the file loaded from cache you can use far future expire header. Query strings won't have any effect for such files.

http://flowplayer.org/tools/performance.html

(section 3)

Far Future Expire header only works if the URL remains the same. A query string is considered as part of the URL in determining whether the object being requested is the same or not

I can understand if you want to put cache-busting into requests from within the swf, however the swf itself must be loaded from the same URL including any query string if you want to take advantage of any expire headers

Just one question, what if the file is serve through a CDN network or any other serverside caching techniques?

I use cache buster only when i want to dynamically load another file that contains dynamic data, this should be a function call from within the scope of the swf, things like loading an xml file that is generated dynamically and or using framework like SWXhttp://swxformat.org needs cache busting. Personally I will not use the cache buster technique within dom level, and i don't think that it is fixing any problem that ie is generating, All i can see is it is doing cache busting with every page load.

The culprit seems to be the following lines from flashembed-1.0.3.js:

147: // prevent possible caching problems
148: e.src += ((e.src.indexOf("?") != -1 ? "&" : "?") + Math.random());

Ideally, there should be an option to turn this on/off. The following patch will give you that:

148c148,151
< e.src += ((e.src.indexOf("?") != -1 ? "&" : "?") + Math.random());
---
> if ( e.autocachebusting )
> {
> e.src += ((e.src.indexOf("?") != -1 ? "&" : "?") + Math.random());
> }
328c331,333
< w3c: false
---
> w3c: false,
>
> autocachebusting: true

autocachebusting in on by default to maintain compatibility. Example usage:

<script>
flashembed("info", { src:"flashvars.swf", cachebusting:false }, {
name1: 'configuration value #1',
name2: 'configuration value #2',
name3: 'Hello World! I am changing'
});
</script>

you are right. this should be an option. I'll add this to the next release of flashembed. Thanks!

Hi,

My company just bought the commercial version, and we have the same issue as mentioned above. I found/removed the relevant cache-busting code in flowplayer-3.1.1.min.js. Just want to make sure this is addressed in the commercial version as well.

Thanks for a great product!

Hi

Did this option ever make it in to the non-commercial version?

I can't see any documentation for it.

It is causing us some problems.

Using Yslow I can see that a single page with multiple flowplayer objects is about 700k where as if the flowplayer object was being reused it would only be about 150k

Cheers

This will be fixed on the upcoming Flowplayer release. Should be out next week. There was a loading error on the Flowplayer SWF object on IE when cachebusting was disabled.