Closed thehowl closed 5 years ago
Instead of hashing each file and saving that info in the application to remember, what could be done is to use the git hash of the gitea build (as in /vendor/assets/octicons/octicons.min.css?34c74126
, where 34c74126
would be appended to all assets). To stop privacy leaks (as not everyone wants that hash to be out in the open) the hash could be something like a sha1 of the startup time of gitea (hopefully people aren't rebooting their gitea instance too often). Or a combination of both (if people are ok with showing the hash that their instance is on, as it is an option in the config, then use that as it would persist across gitea reboots, but fallback to a sha1 of startup time).
what could be done is to use the git hash of the gitea build
Thought of that, but if an user changed the file by placing it in the custom/ folder, then the cache wouldn't be invalidated.
the hash could be something like a sha1 of the startup time of gitea (hopefully people aren't rebooting their gitea instance too often)
I tend to agree with this much more.
I would still reather see it to be hash of the file
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
This issue has been automatically closed because of inactivity. You can re-open it if needed.
Currently, assets are linked directly from the generated HTML, and they are cached by the browser, even more so after #3376. To avoid the website breaking when a Gitea instance is updated, we should probably add at the end of links to JS/CSS and assets a timestamp or a MD5/SHA1 hash of the file, in order to help tell the browser when it has been updated (in spite of the
Expires
on the request); for instance, like this:/vendor/assets/octicons/octicons.min.css?1516470750
or/vendor/assets/octicons/octicons.min.css?34c741261b8c1fe08cde34db14773785