Last modified: 2014-08-27 11:51:19 UTC
All Wikimedia Javascript and CSS files which have Cache-control set to public and are not having their cache headers overwritten by the Squid servers are getting a 30 days max-age param added onto their cache-control header, even if they already have one. Here are some examples: http://en.wikipedia.org/w/index.php?title=-&action=raw&maxage=2678400&gen=css Cache-Control:public, s-maxage=2678400, max-age=2678400, max-age=2592000 http://en.wikipedia.org/w/index.php?title=-&action=raw&gen=js&useskin=vector&283-17 Cache-Control:public, s-maxage=2678400, max-age=2678400, max-age=2592000 http://en.wikipedia.org/w/index.php?title=Special:BannerController&cache=/cn.js&283-17 Cache-Control:public, s-maxage=3600, max-age=3600, max-age=2592000 The 30 day max-age appears to be coming from the following Apache config: ExpiresActive On ExpiresByType image/gif A2592000 ExpiresByType image/png A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType text/css A2592000 ExpiresByType text/javascript A2592000 ExpiresByType application/x-javascript A2592000 This is likely a minor problem in most cases, but is a significant problem for the fundraising effort, since CentralNotice banner lists are not supposed to be cached for more than 5 minutes on the client side.
As a short-term band-aid, what if we reduced the last two directives to 1 week instead of 30 days?
To paraphrase a discussion Kaldari and I just had on IRC: since some MediaWiki Javascript and CSS doesn't have a cache-control header by default, we currently need some form of Apache config to add it if it's not there. Unfortunately, using the Apache config adds it in places we rather it wasn't. The "right" way of fixing this is tracking down a lot of extension authors and making sure they are always adding a cache-control header. That's assuming we should require that of extension authors; we certainly need it on the WMF cluster, but that may not be required in many contexts. Kaldari thinks it may be possible to fix this in Setup.php (i.e. making sure it sends a Cache-control header by default). This would allow us to turn off ExpiresActive in the Apache config.
(In reply to comment #2) > The "right" way of fixing this is tracking down a lot of extension authors and > making sure they are always adding a cache-control header. That's assuming we > should require that of extension authors; we certainly need it on the WMF > cluster, but that may not be required in many contexts. > The even better way of fixing this is to deploy ResourceLoader, which makes all these concerns go away :D Of course that won't happen for a little while longer.
The short term fix of lowering the default Apache cache has been put in place.
Since Resource Loader is (I think) being used now, can this be closed?
I think Resource Loader is going out tomorrow. Also, I might have to update some things in CentralNotice to take advantage of it. Not sure yet how it will affect this bug exactly.
From triage, Tim offers this fix: ExpiresByType can be set in a <Directory> section. We still do send some static files so ExpiresByType can be set for the directories that they are in
Ryan, before we do anything with this: RL has been out for a few months. Do we still need to update the apache configs? If so, which directories should we put the ExpiresByType directives on?
(In reply to comment #8) > Ryan, before we do anything with this: RL has been out for a few > months. Do we still need to update the apache configs? If so, which > directories should we put the ExpiresByType directives on? Yes, some files bypass RL, and RL's debug mode also loads files directly. We need it for JS/CSS files in the skins and extensions directories.
Agree with Roan's comments. This issue is less of a problem now, but it would still be good to fix for the cases described.
Assigning this to Chad since we now have the information he requested.
Please file bugs per extension if you want this for a particular extension. Otherwise, we'll rely on ResourceLoaderfication for the ultimate solution to this.
