Searching for info about Flash’s caching mechanism turned up endless posts on how to prevent caching, but none mentioned how LoadVars.load() handled server-sent Cache-Control headers. So I tested this myself.
In the SWF, I loaded the same URL once every 5 seconds using setInterval() and LoadVars.
The URL ran a PHP script that sent content along with Last-Modified and ETag headers based on its own mtime, and the header Cache-Control: max-age=0, private, must-revalidate. This basically means “browsers may cache this item, but must always check the server for updates before using it.”
It worked! Once Flash got those headers, load() would then make “conditional” GET requests: Flash included If-None-Match and If-Modified-Since headers, allowing PHP to respond with 304 Not Modified, and Flash used its cached copy of the data.
Flash seems to use the browser as a proxy to handle these requests and manage the cache, because Flash in Safari 3 shared a limitation of that browser, namely not supporting ETags; Safari only sends back an If-Modified-Since header for conditional GETs.
Interesting and a worthwhile exercise – thank you.
Do you know if this work the same for standalone Flash apps?
I should also note that Fiddler is essential for thoroughly debugging HTTP caching. Firebug hides the 304 status codes and sometimes entire requests.
@Steve, totally agree… i don’t like Firebug not Life HTTP headers,
specially for the 304 headers, it basicly sucks and it’s best to get something like Service Capture or other tools that capture data on the wire.
Ries