Use cache immutable

[andymckay]

http://bitsup.blogspot.ca/2016/05/cache-control-immutable.html?m=1

This will cut down on all those super fast 304 hits, as long as our URLs are definitely immutable. Rumour has its landing in Firefox 49.

[muffinresearch]

@bqbn when you have a moment could you look at adding this to all our statics served from the CDN that currently have far-future expires?

[bqbn]

Yep, I'll try to implement this next week.

[bqbn]

This is filed under addons-frontend repo, but I assume this is for the desktop site as well?

[kumar303]

I assume this is for the desktop site as well?

I think we only want it for assets served from the CDN

[bqbn]

I assume this is for the desktop site as well?

I think we only want it for assets served from the CDN

So I assume the answer to my question is yes, since the desktop site uses CDN too.

[muffinresearch]

So I assume the answer to my question is yes, since the desktop site uses CDN too.

Yes any static assets that are currently served with far future expires and require a url change to bust cache.

[bqbn]

This is now on -dev and -stage.

[muffinresearch]

Looks good to me:

CSS:

JS:

@bqbn Out of interest I note on this response there are two headers rather than one:

[bqbn]

This is now on -prod as well.

I notice that files that are already in CDN before today's release will still get 304. But if you change the number in the query string to some random value, it'll force the CDN to talk to the origin (nginx in this case) to retrieve the file and the immutable header.

I don't know if it's worth the effort invalidating our CDN cache though. One side effect of doing that is more requests will hit the origin and increases its load. I think overtime with new releases coming out, more and more files will get the immutable cache-control header.