Set cache headers on pv-mirror*

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: nthomas, Assigned: jakem)

Tracking

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
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.
(Assignee)

Comment 3

6 years ago
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
(Assignee)

Comment 5

6 years ago
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
Last Resolved: 6 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.