I observed that chrome cached a relevant video file. I changed it with a different one around the server and chrome stored serving that old one from cache (using JW expensive player 5)
The headers from the request seem like this:
joe@joe-desktop:~$ wget -O - -S --spider http://www.2xfun.de/files_geheimhihi14/20759.mp4 Spider mode enabled. Check if remote file exists. --2011-05-15 22:40:56-- http://www.2xfun.de/files_geheimhihi14/20759.mp4 Resolving www.2xfun.de... 18.104.22.168 Connecting to www.2xfun.de|22.214.171.124|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sun, 15 May 2011 20:40:56 GMT Server: Apache Last-Modified: Sun, 15 May 2011 20:37:59 GMT ETag: "89b38-3bb227-4a35683b477c0" Accept-Ranges: bytes Content-Length: 3912231 Cache-Control: max-age=29030400, public, must-revalidate Expires: Sun, 15 Apr 2012 20:40:56 GMT Connection: close Content-Type: video/mp4 Length: 3912231 (3.7M) [video/mp4] Remote file exists.
I'm using mod_headers and mod_expires in apache2 such as this:
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|mp4)$"> ExpiresDefault A29030400 Header append Cache-Control "public, must-revalidate" </FilesMatch>
Did I spell revalidate wrong or something like that?
To create the utilization situation obvious: I would like the files to become cached, since they're rather large and I wish to save bandwidth. But however I would like the files to become re-validated. Therefore the client does a Mind request and inspections if the content has transformed (thats exactly what the etag is perfect for), and just re-brings if required.
Your condition is the fact that must-revalidate only takes over when a cache entry is no more fresh, but you've marked the response as cacheable for 29 million seconds. 'Cache-Control: max-age=, must-revalidate' might be nearer to what you would like, if you wish to allow caching but require revalidation on each use.