Closed Bug 707560 Opened 13 years ago Closed 12 years ago

Set cache headers on pv-mirror*

Categories

(mozilla.org Graveyard :: Server Operations, task)

x86
All
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nthomas, Assigned: nmaul)

Details

Spun off from bug 703729, in particular comments #2 through to 8, where we tried to purge files from download-cdnetworks.mozilla.net but weren't successful.

We probably need to retest to verify the problem, filing in IT since they have access to the purge UI.
Having an cache expiry shorter than a week might also be helpful.
(In reply to Nick Thomas [:nthomas] from comment #1)
> Having an cache expiry shorter than a week might also be helpful.

Yes, and can we standardize our CDN cache expiry?  I suggest not more than 24 hours.
In reading that bug, it looks to me like someone was able to verify that the cache purge was successful, which leads me to believe there was some sort of timing issue between when the purge was happening and the files were being used. We'd need some way to retest to be sure of this. IMO it's pretty unlikely that the purge tool is just not working, and more likely that either we didn't purge what we wanted to, or we got the timing mixed up.

As far as the expiry, we do have a standardized CDN cache policy- we typically have the CDN cache according to the standard headers returned by the origin server. The usual Cache-Control: max-age=<whatever>, Expires: <whatever>, etc. If those are present, the CDN should honor them. This lets each web dev make whatever decisions make the most sense to them, and we generally don't require any special CDN configs. This also makes for good habits which can carry over into non-CDN sites/content. :)

As far as I can tell the origin in this case (pv-mirror01) isn't setting any cache headers, and I think this is causing CDNetworks to default to a 1-week time. A good way to check would be to have the origin start setting some good headers (Apache can do this fairly nicely), and see how the CDN reacts.
Over to Jake.
Assignee: server-ops → nmaul
On the original topic of this bug (investigate failure to purge), I don't think there's anything we can do. I'm fairly sure we probably just messed up the timing a little bit and ended up in a situation where some nodes re-cached the old content.

So, I'm changing the topic of this to be about setting cache headers. That's something we definitely *can* do something about. :)

After some discussion in #build, we have settled on this:

    ExpiresActive on
    ExpiresDefault "access plus 1 day"

This is a 1-day Expires header on all content served from pv-mirror01 and 02. Locally this is already functional. On the CDN, some things will already be cached with the older CDNetworks-default-1-week max-age... those will expire naturally and pick up the new 1-day setting over the next week.

I have tested with an unlikely-to-be-cached file (random locale, old version), and it works- the CDN returns a 1-day Expires header to the user, along with a 1-day max-age.


I'm going to close this bug out. If we need any additional work here, we can re-open. :)

Thanks!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Summary: Investigate failure to purge files from cdnetworks CDN → Set cache headers on pv-mirror*
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.