Last modified: 2013-07-30 01:25:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42532, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40532 - cache headers for BannerListLoader are being overwritten by squids
cache headers for BannerListLoader are being overwritten by squids
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
master
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-26 18:55 UTC by Ryan Kaldari
Modified: 2013-07-30 01:25 UTC (History)
6 users (show)

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


Attachments

Description Ryan Kaldari 2012-09-26 18:55:30 UTC
While QA testing CentralNotice today, I noticed a significant change from last year...

The caching headers for the BannerListLoader are different than they were last year. Last year they were...

Cache-Control:public, s-maxage=300, max-age=300, max-age=604800 (yes, that's 2 max-ages, see bug 26338)

Now they are...

Cache-Control:private, s-maxage=0, max-age=0, must-revalidate

This makes me think that the cache override override (yes, double override) solution we were using isn't working any more. The practical effect of this is that loading banners on subsequent pageloads (after the first) will take about half a second longer (or worse for slow connections). No idea if this is related to the lower banner impressions, but it's definitely something we want to fix. Unfortunately, I have no idea how to reliably escape the squid cache overrides. Indeed it may not even be possible anymore. Regardless, we need to figure out a way to override the override, and preferably with a non-hackish solution that will be reliable (and free from cache interference from the Apaches as well).
Comment 1 Matt Walker 2012-09-27 00:17:00 UTC
Hopefully https://gerrit.wikimedia.org/r/#/c/23307/ fixes this for CN (See api/ApiCentralNoticeAllocations.php) -- but would still be nice to know proper method for Special Pages.
Comment 2 Asher Feldman 2012-10-12 00:05:34 UTC
The bcache=1 query param now tells squid not to disable browser caching.

Testing with:
curl -v 'http://en.wikipedia.org/w/index.php?cache=%2Fcn.js&title=Special%3ABannerListLoader&language=en&project=wikipedia&country=US&bcache=1'

And the response contains:

Cache-Control: public, s-maxage=300, max-age=300
Comment 3 Peter Gehres 2012-10-12 00:07:55 UTC
Does that mean that we can remove the cache=%2Fcn.js from the URL?
Comment 4 Ryan Kaldari 2012-10-12 00:21:48 UTC
Yes.
Comment 5 Ryan Kaldari 2012-10-12 00:25:03 UTC
Reopening until the URL change is applied to bannerController.js.
Comment 6 Matt Walker 2012-10-15 23:10:02 UTC
What if we want our squids to cache it; but not any intermediate cache server?

IE: Our swuids rewrite public to private?
Comment 7 Asher Feldman 2012-10-15 23:15:51 UTC
(In reply to comment #6)
> What if we want our squids to cache it; but not any intermediate cache server?
> 
> IE: Our swuids rewrite public to private?

Then don't use urls with bcache=1.  By default, the frontend squids rewrite cache-control like so:

header_replace Cache-Control private, s-maxage=0, max-age=0, must-revalidate
Comment 8 Adam Wight 2012-10-21 15:32:47 UTC
BannerListLoader is probably being deprecated this week.
Comment 9 Matt Walker 2013-07-30 01:25:44 UTC
BannerListLoader is done for a while ago -- this is no longer relevant.

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


Navigation
Links