gateway: no-cache on GET (fix stale web listing after upload)#48
Merged
Conversation
…eb listing) The web app showed a STALE folder/bucket listing after an upload: it runs on browser fetch, which heuristically HTTP-caches GET responses that carry no Cache-Control. The forest index (the listing source) is read at an encrypted, per-user-derived key the gateway cannot single out, so the browser served a cached old index for minutes. Native is unaffected (reqwest has no browser cache) -- exactly why native refreshed instantly and web did not. Fix: default GET responses to Cache-Control: no-cache (revalidate-always). The browser now re-checks every object via its ETag: - the index changes on each write -> conditional GET misses -> 200 FRESH index -> listing always current; - unchanged file content -> ETag matches -> 304 (already handled at the If-None-Match block) -> browser serves the cached body, NO re-download. Listings stay fresh while downloads stay cached -- no blanket cache-disable, no client change. A stored per-object cache_control still wins. Gateway-only: no SDK publish, no web redeploy. Deploy the gateway to take effect. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
1 participant
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.
Gateway-only fix for the web stale-listing-after-upload bug (a newly uploaded file does not show after Refresh, though it is on the server).
Root cause: the web app runs on browser fetch, which HTTP-caches GET responses. The gateway sends no Cache-Control, so the browser heuristically caches the encrypted forest index (the listing source) and serves a stale copy for minutes. Native uses reqwest (no browser cache) -- which is exactly why native refreshes instantly and web does not.
Fix: default GET responses to Cache-Control: no-cache (revalidate-always). The browser re-checks every object by ETag -- the index changes on each write so it returns 200 FRESH, while unchanged file content returns 304 (already handled) and is served from the browser cache with no re-download. Listings stay fresh AND downloads stay cached. A stored per-object cache_control still wins.
Scope: gateway-only. No SDK publish, no app rebuild. Fixes web + native + future clients. Deploy the gateway to take effect. Full rationale in the commit message.
Generated with Claude Code