Natty to describe problem that I think is related to ms-files.php new in WP3.x and how it handles uploaded files. First off, this worked as expected in WP < 3.x.
Set Cache-Control headers in .htaccess using FilesMatch, with or without using Expires headers (here included):
# 1 YEAR <FilesMatch "\.(ico|png|jpg|gif|pdf|swf|flv|doc|mp3|mp4|mov|avi)$"> ExpiresDefault A29030400 Header set Cache-Control "max-age=29030400" </FilesMatch> # 6 WEEKS <FilesMatch "\.(css|js)$"> ExpiresDefault A3628800 Header set Cache-Control "max-age=3628800, proxy-revalidate" </FilesMatch> # 1 HOUR <FilesMatch "\.(html|xml|txt)$"> ExpiresDefault A3600 Header set Cache-Control "max-age=3600, private, must-revalidate" </FilesMatch> # NO CACHE <FilesMatch "\.(php|pl|cgi)$"> ExpiresActive Off Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform" </FilesMatch>
Check the page loading with FireBug and ONLY media files loaded from:
show the Cache-Control as being
"private, no-cache, no-store, proxy-revalidate, no-transform"
as it should be. It's as if the FilesMatch rules are being re-written, ignored or a .php extension is being appended if files are found in the upload location, because they are not being recognized as having a Cache-Control specification for their type. The specification for the
files is being applied instead, which points to a .php extension and possibly a dreaded version being added to the filename defeating the rule.
WP theme files and files loaded from an external domain all exhibit the correct Cache-Control headers. Only the upload location exhibits this anomaly and they are the only ones served through ms-files.php.
I then checked this on a second WP3.x install that does not have the domain mapping plugin running and the blogs over there do the same exact thing, so it's not the domain mapping plugin getting in the mix.
All other domains on the server not using WP3.x work as expected, exhibiting the correct Cache-Control headers on the correct file types.
Looking at the ms-files.php code, I see lines in there attempting to set Expires, Last-Modified and ETag caching headers, where a server admin would set them specifically elsewhere. Don't see anything related directly to Cache-Control but the above code, or code in wp-load.php could be messing with already set header specifications.