Last modified: 2014-08-27 11:51:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 26338 - Wikimedia Javascript and CSS files are getting an extra max-age cache-control param
Wikimedia Javascript and CSS files are getting an extra max-age cache-control...
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-14 18:34 UTC by Ryan Kaldari
Modified: 2014-08-27 11:51 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ryan Kaldari 2010-12-14 18:34:55 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.
Comment 1 Ryan Kaldari 2010-12-15 02:43:45 UTC
As a short-term band-aid, what if we reduced the last two directives to 1 week instead of 30 days?
Comment 2 Rob Lanphier 2010-12-21 19:39:35 UTC
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.
Comment 3 Roan Kattouw 2010-12-21 21:09:47 UTC
(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.
Comment 4 Ryan Kaldari 2010-12-22 19:23:13 UTC
The short term fix of lowering the default Apache cache has been put in place.
Comment 5 Mark A. Hershberger 2011-01-29 14:15:02 UTC
Since Resource Loader is (I think) being used now, can this be closed?
Comment 6 Ryan Kaldari 2011-02-07 18:17:09 UTC
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.
Comment 7 Mark A. Hershberger 2011-07-15 14:44:04 UTC
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
Comment 8 Mark A. Hershberger 2011-07-15 15:00:38 UTC
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?
Comment 9 Roan Kattouw 2011-07-15 17:53:19 UTC
(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.
Comment 10 Ryan Kaldari 2011-07-16 00:40:03 UTC
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.
Comment 11 Mark A. Hershberger 2011-07-16 20:42:48 UTC
Assigning this to Chad since we now have the information he requested.
Comment 12 Rob Lanphier 2011-11-15 21:28:10 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links