docs(deployment): drop immutable from nginx /uploads/ cache header#62
Merged
Conversation
bigin
force-pushed
the
fix/uploads-cache-immutable
branch
from
May 25, 2026 16:09
be4ff12 to
17f0729
Compare
The nginx snippet in docs/deployment.md recommended `Cache-Control: public, immutable` for `/uploads/`, which is wrong for iManager's FileStorage layout. FileStorage writes to `var/uploads/<itemId>/<fieldId>/<filename>` keeping the user's original filename. Re-uploading a file under the same name leaves the URL stable while the bytes change. With `immutable` set, browsers serve the stale bytes for up to 30 days (the `expires` window) and skip revalidation entirely. Switch to `Cache-Control: public, must-revalidate` and add an inline comment explaining the choice. The 30-day expires window is kept; browsers now send `If-None-Match` on every hit and nginx's built-in ETag answers 304 cheaply when the file is unchanged, 200 with the new bytes when it changed. The Caddy snippet in the same section was already correct (no explicit Cache-Control, default revalidation), so it stays untouched. CHANGELOG entry under Unreleased / Documentation. No code or behavior change. This mirrors the same fix applied to Scriptor's docker/nginx.conf in scriptor#fix/uploads-cache-immutable (the bug surfaced there when re-uploading the same-named image kept showing the old one).
bigin
force-pushed
the
fix/uploads-cache-immutable
branch
from
May 25, 2026 16:12
17f0729 to
bab4c85
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The nginx snippet in docs/deployment.md recommended
Cache-Control: public, immutablefor/uploads/, which is wrong for iManager's FileStorage layout.FileStorage writes to
var/uploads/<itemId>/<fieldId>/<filename>keeping the user's original filename. Re-uploading a file under the same name leaves the URL stable while the bytes change. Withimmutableset, browsers serve the stale bytes for up to 30 days (theexpireswindow) and skip revalidation entirely.Switch to
Cache-Control: public, must-revalidateand add an inline comment explaining the choice. The 30-day expires window is kept; browsers now sendIf-None-Matchon every hit and nginx's built-in ETag answers 304 cheaply when the file is unchanged, 200 with the new bytes when it changed.The Caddy snippet in the same section was already correct (no explicit Cache-Control, default revalidation), so it stays untouched.
CHANGELOG entry under Unreleased / Documentation. No code or behavior change.
This mirrors the same fix applied to Scriptor's docker/nginx.conf in scriptor#fix/uploads-cache-immutable (the bug surfaced there when re-uploading the same-named image kept showing the old one).