Can't believe the caching bug is STILL there

Question

Hi,
I MUST be missing something. It can't be true that this has not been fixed after so many years.
So well, the problem is, every time you load an external asset or file, say for example using a Loader object or a URLLoader object (the same happened in AS2 with MovieClipLoader, LoadVars, XML.load() etc etc, and even before with loadMovie, etc) - every time you load a file, the Flash Player caches that file, and this is independent from your browser: it is Flash Player's own (and primitive) caching mechanism.
Whenever you load a file with the same URL again, no matter whether the file has been changed or not, Flash Player will use the cached copy, and there's NO WAY to prevent that - there are a few workaround that I will discuss later but they don't solve the problem completely, besides being terribly combersome.
Now, the HTTP protocol has a wonderful mechanism to manage the caching of files in an intelligent way, which has been working for years and, I think, was invented even before flash existed, however at least 10 years ago, and it works fine.
If an HTML page has an IMG tag with an image, for example, and if the browser has already a cached version of the image with that URL, the browser will first ask the server for that file and declare it has a cached version with date xxx; if the server's file is not newer than xxx, then the server replies that the file has not changed and the browser can use its cached version (or insist to redownload it if he wishes). But if the file on the server is newer, the server will reply with the new file, and the browser will NEVER show an obsolete cached version of the image (or whatever file).
Now, I don't know why, Flash Player was designed in a very primitive way that ignores this whole mechanism provided and standardised by the HTTP protocol. Flash Player will ALWAYS use a cached version of the file if he has one, it won't worry about veryfying whether it is obsolete or not.
So, unless the user clears its cache, whenever you update an xml, txt, jpg or whatever file that is loaded within your flash application, users that have previously visited the page may still see the old version.
Now, there's an easy workaround for ensuring that a cached version of the file is NEVER used, which is appending a "?somerandomname="+n to the filename, where n is obtained for example as n=(new Date()).value(); in order to ensure that it is always different.
This way, the complete url of the file is always different and the cached version will never be used.
However, this is not a solution either. For small text files it is ok, but for images and swf's for example, you DO want the cached file to be used IF it is not obsolete. Otherwise, returning visitors will always have to wait for the complete download time of everything, including files that have been downloaded yesterday and have not been modified.
So, this problem has been solved ages ago by the HTTP protocol, but the Flash Player is naive and ignores it.
I used to use 2 workarounds: the one I have mentioned for small files (texts, xml's), and the following one for files that can be updated every once in a while:
In the main html page, I append "?lastupdate=dddddd" to the swf name, where dddddd is a manually edited date of the last time something relevant has been updated. So for example:
<object ....... etc etc> <param name="movie" value="mainswffile.swf?lastupdate=20090625"/>... <embed etc etc etc src="mainswffile.swf?lastupdate=20090625"/></object>
Or something like that.
When I update some of the files that are to be loaded, I manually edit the "lastupdate" thing in the html.
Then in the ActionScript programming I use the _root.lastupdate variable to append to the filenames of images or assets I load.
All this is horribly cumbersome and error-prone. Image you deploy a website to a client that will be able to update his own texts and images: you have either to explain him how to edit the html file also, or create some complicated server-side or client-side script to manage the cache-avoiding system. That is, reinventing the wheel, in this case the cache.
Every time a new version of the player was released, I expected it to fix the stupid caching problem and to make my cumbersome tricks obsolete and unnecessary.
I expected to see that the new version would make proper use of HTTP caching protocol specifications, and use cached files ONLY when they are not outdated, after verifying it with the server according to the HTTP protocol.
Every new version of the player was a disappointment.
Then I hope the new version of the language, Action Script 3.0, would fix this.
No, it seems it doesn't.
I've done some tests with AS3 and with my great and sad surprise, the caching "bug" is still there.
Well, the bug, not the "bug": this is a bug proper, because there's no reason why it should work this way.
So, my question is.
Maybe am I missing something? Is there a way, by using some method or property of URLLoader, Loader and/or URLRequest, to tell Flash Player to use the cache in an intelligent way? I mean, in a not-astonishingly-stupid way?
Note that I'm not talking about forcing it to NOT USE cache at all: I mean using a cached version when it is appropriate, and redownloading the file when needed, as all decent http application have done for years.
Perhaps there IS a way to solve this.... It should be the default behaviour and should be transparent, but however, if there is a SERIOUS fix (not a hackaround), that would at least solve the problem.
Do anybody know of a method that really works?
(I have read of people trying by using http headers with caching directives but without success; or in the best case maybe they were able to force never-caching, which is NOT a solution as I explained)
Thanks in advance.
And if there is any Adobe developer listening, please fix this bug since it is really a shame that an application written in 2008 or 2009 suffers from a problem that was elegantly and definitely solved in the XX century.
Regards,
m.

Answer 1

I wrote a long reply and when I posted it it vanished.
I had even control+c'opied it before submitting but it didn't even get into my clipboard.
Shame on this forum (sorry to say that, but that's what I have to say).
So, I'll try to write it again but it won't be the same: the amount of rage is augmented.
Thank you BWolfe for letting me know that Flash now (since last year) has a bug management system. It was also such an enormous shame that it didn't have one.
Adobe used to confuse bug reports with feature requests; now this kind of confusion is still partially there and it is reflected by the voting thing, which is an absolute aberration. In a decent bug management system, the developers take the responsibility to give the bugs the priority they deserve; and no matter how low the priority, even the smallest bug ALWAYS get into the queue.
Now this bug we are discussing has been well known for AT LEAST EIGHT YEARS and I am not exaggerating at all, as I started using flash in 2001 and the issue was already mentioned here and there in forums etc; probably some blind people didn't see it as a bug (rather as a situation you have to face or work around), but it was known. And the very solution, as I already pointed out, was there even before Flash was conceived (well, for the sake of scientifical rigour, I should say, before Flash was commercialized): the HTTP protocol has the capability to perfectly manage file caching in a manner transparent to the higher layer.
So, since I don't believe that nobody at Adobe (formerly Macromedia) has heard about a bug that every intermediate-level actionscript developer in the world knows of, it is already kind of a shame that we have to report it in 2009, but that's ok. But that we have to get votes, no, that's an insult.
Jesus, ActionScript is a programming language, man, A PROGRAMMING LANGUAGE... it is not like Photoshop or Premiere; and it seems like in so many years, people who manage it haven't yet realised it completely.
Big Brother contestants should be voted. Feature requests may be voted. Bugs cannot be voted should just be fixed one by one as soon as possible.
Well, sorry for the rant and thank you for the answers.
Hope this gets through this time.