Hi Nathan, The urls are the best way IMHO. Check out my blog entry on the subject: http://neo-archaic.ie/blog/2006/08/nocache-for-javascript-and-flash/
Cheers, Karina > -----Original Message----- > From: [email protected] [mailto:flashcoders- > [email protected]] On Behalf Of Nathan Mynarcik > Sent: 10 March 2010 2:03 > To: Flash Coders List > Subject: Re: [Flashcoders] Apparently Doesn't Check Cache > > I actually have experienced the reverse of this issue. Flash caches the > dynamic content so hard that I have reverted to using no_cache meta > tags in my HTML. > Not to OT the topic, but are meta tags the best way to prevent this? I > have even though of adding a variable at the end of my dynamic urls > with a date element so flash would constantly think its a new XML doc > to load everytime. > > > Nathan Mynarcik > Interactive Web Developer > [email protected] > 254.749.2525 > www.mynarcik.com > > -----Original Message----- > From: [email protected] > Date: Wed, 10 Mar 2010 13:46:08 > To: Flash Coders List<[email protected]> > Subject: Re: [Flashcoders] Apparently Doesn't Check Cache > > Every request for a file will go back to the server at some level. For > example, despite the fact that have a file "preloaded' into cache when > another request is made for the file it will look at the cache then > send a request to the server to see if the file has changed or whether > the file in cache is valid to use. If the server returns "use file from > cache" then it will use the cached file otherwise it will load the > "revised" version from the server. > > First questions would then be what is the header returned as part of > the original file request. Is it no-cache or does it set a very short > expiry? Are the url's exactly identical or is there any kind of query > string associated with the url of one request but not the other? This > might be walking on thin ice here, but can you see the file in the > browser's cache? Back in the day, when I was doing Director > development, there was a period of time that elapsed from when > "Shockwave" loaded the file and the time that it went into the > browser's cache. The file was always available within the Shockwave > environment but it was immediately visible in the browser's cache. > Don't know if a similar situation arises with Flash where the content > is loaded but hasn't yet been written into the browser's cache. > > I'd honestly start out by using something like Internet Explorer where > you can easily browse the cached files -> blow away the cache and then > load your swf preloader app. See if the files are in cache. If they are > cool, note the URL associated with them. Then I'd go back and clear the > cache again and re-run the app with the new window code in place. I'd > run it through to completion and see if there are two copies of said > image in cache one from the swf preloader and the other from the new > window. If so it would imply that they must be seeing slightly > different urls. If not then I'd be looking for no cache headers. > Concurrent to this I'd be using something like Fiddler (IE), Charles or > Tamper Data or similar app that will allow you to see the requests and > the responses and be able to examine the headers and check for no-cache > or very short expiry on the headers. > > Theoretically what you are doing should work, I can't see how placing > the image on stage would make any difference. Everything is always a > possibility but using a test strategy that stepwise verifies what is > getting written into cache and what the request are for the files is a > good first step in eliminating many issues. > > Sincerely > Mark R. Jonkman > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
