Suspected Caching on Glycam Actual causing site to break.

[gitoliver]

When using Brave on actual when I try to build anything it gets stuck trying to load on the options page. I see a 404 error:
https://jam.dev/c/6e917a04-eee1-4bb1-9a18-e01c560784f1
If I try in a private tab or in Firefox actual works fine. I have no idea how often this is occurring for users.

We need to somehow force cache flushes?
https://webmasters.stackexchange.com/a/138269
The relevant part of that answer being:
You should set proper cache control headers so that you don't have this problem again in the future. Rather than making browsers guess how long they can cache pages, you should explicitly tell them.

For a site based on Apache, you can put something like this in your .htaccess file:

Default caching: 1 day

Header set Cache-Control "max-age=84600, public"

Resource caching: 1 week

<FilesMatch ".(ico|jpg|jpeg|png|gif|svg|webp|pdf|js|css)$">
Header set Cache-Control "max-age=592200, public"

That would mean that everybody gets new HTML within 24 hours and changes to images and scripts with in a week. I usually recommend longer cache times for resources because changes to them can be forced by using version parameters on their URLs.

Tool:
glycam.org/txt with DManpa1-OH (or anything)

[danwentworthart]

We have been avoiding caching issues in the past by renaming the CSS file. New file name causes it to load. Perhaps this behavior doesn't work in Brave. I will test and see.

I can implement what you shared, but the advantage to the filename edit is that it changes when it needs to, rather than some arbitrary guess at a time span.

If I can preserve the benefits I describe I will, otherwise I can fall back on the advice you shared.

[danwentworthart]

Bringing Andrew into the conversation, because as I looked into this, it seems that my area of the stack is not where caching occurs. Perhaps we can discuss in person at next webdev meeting.