Page MenuHomePhabricator

Wikimedia Javascript and CSS files are getting an extra max-age cache-control param
Closed, DeclinedPublic

Description

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.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=17821

Details

Reference
bz26338

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:22 PM
bzimport set Reference to bz26338.
bzimport added a subscriber: Unknown Object (MLST).

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.