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...
Connecting to www.2xfun.de||: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"

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.