Why does Plug.Static not define an cache expiration date by default?

kiru

We are using Phoenix with Plug.Static to serve static files (e.g. images and js files).

Some images were not cached in the borwser, and it turned out we were not using Routes.static_path(@conn, "images/bla.png") instead, we just added the path like this: <img src="images/bla.png" />.

I see in the browser, that the server replies with the following response headers:

cache-control: public
Connection: keep-alive
Date: Mon, 16 Jan 2023 13:15:03 GMT
etag: “52BBD1A”

This is correct, since public is the default value for cache_control_for_etags. I tried to understand what the default (without explicit expiration date) exactly means, but the online resources are a bit sparse.

This SO answers recommends not to use “Cache-control: public” at all, while this article recommends not to put a max-age at all:

97.3% of responses containing it [Cach-control: public] have max-age or s-maxage too, making it redundant

So far, what I understood is that by omitting the expiration date, the browser (or the CDN in between) guesses the expiration value using some heuristics (source).

My question is the one stated in the topic, why does “public” without expiration makes sense as the default value?

I am not sure if this is the correct place to ask. Thank you in advance for answering.

Kiru

3 comments

/phoenix #plug #caching

1 1103 3

2023-01-16 16:37:35 UTC

First 3 of 3 Posts

BartOtten

The SO answer you link to is not advising against ‘public’ for static assets, but setting it as default for all responses. Even responses with private data could end up in a cache of you and all parties in between with such default.

The article is about using a value for max-age, which means you know better than heuristics. Sometimes a developer does, most of the times they don’t.

Now for Plug…

For static assets, the etag is used. This is a check-value based on the content or metadata of a response. When the browser needs something it already cached once it will communicate with the webserver if that check-value is still current. If it is, the file is not returned over the wire and the browser uses the cache. So this method always requires a call, but server software is extremely fast at answering those (they already know the checksum of the file as they cache the checksum!).

As soon as the check-value changes the cache is cleared for that item.

So the default of Plug says: you (and everyone in between) can cache this asset as long as you like as we trust your heuristics. However, if the content changed you’ll need a fresh copy.

Post #1

LostKobrakai

If the request query string starts with “?vsn=”, Plug.Static assumes the application is versioning assets and does not set the ETag header, meaning the cache behaviour will be specified solely by the cache_control_for_vsn_requests config, which defaults to "public, max-age=31536000".

That’s the default for phoenix when using static_path though, which is explicitly not using etags. Though I’m not really sure as to why exactly.

Post #2

BartOtten

Because now the file can have other properties on disk without having a ‘uncached’ etag status.

Common implementations use the ‘file modified’ property for etag generation as it’s cheap to get by. As a result a re-compile of assets might make all assets uncached even when the content of only one has changes.

So it’s about taking control of the cache-status from the webserver to the (asset generating) application.

Post #3

— All posts loaded —