Well, this is a shot in the dark, but I came across situations where Apache did not respect my .htaccess headers, and I had to "force" them using the always keyword:
<FilesMatch "\.(js|css|ttf)$"> Header always set Cache-Control "max-age=604800, public" </FilesMatch> <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$"> Header always set Cache-Control "max-age=604800, public" </FilesMatch> <FilesMatch "\.(html|htm|php)$"> Header always set Cache-Control "max-age=60, private, proxy-revalidate" </FilesMatch> <FilesMatch "\.(css|js|gif|jpeg|png|ico)$"> ExpiresActive On ExpiresDefault "access plus 1 year" </FilesMatch>
When your action is a function of an existing header, you may need to specify the condition always, depending on which internal table the source header was set to. A table that always matches is used for locally generated error responses as well as successful responses. Note also that repeating this directive with both conditions makes sense in some scenarios, because it is not always a superset of onsuccess with respect to existing headers:
- You add a header to the locally generated response without success (not 2xx), such as a redirect, in which case the final answer uses only the table that always matches.
- You change or delete the header generated by the CGI script, in which case the CGI scripts are in the table corresponding always, and not in the default table.
- You modify or delete the header generated by some part of the server, but this header was not found by default onsuccess condition.
From Apache Module_headers
source share