fix(userscript): bypass browser HTTP cache when fetching registry index - #827
Merged
Conversation
jsDelivr serves branch-ref URLs with cache-control max-age=604800 (7 days), and GM_xmlhttpRequest goes through the browser HTTP cache, so a userscript could replay a stale registry index for days and never see new SitePacks. The extension transport already uses fetch with cache: no-store; the userscript transport has no such option, so append a timestamp query parameter instead: jsDelivr ignores query strings when resolving content, while the browser keys its cache by full URL.
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.
Problem
The userscript build could keep showing an outdated online adapter library for days no matter how often users checked for updates.
Root cause: jsDelivr serves branch-ref URLs (e.g.
@registry-dist/index.json) withcache-control: public, max-age=604800(7 days).GM_xmlhttpRequestgoes through the browser HTTP cache, so every update check replayed the cached response and the request never reached jsDelivr. Observed in practice: a userscript stayed on registry revision 17 (published Aug 12) while the registry was already at revision 25. The raw.githubusercontent.com fallback source never kicks in because a cached response counts as success.The extension is not affected: its registry transport already uses
fetch(url, { cache: "no-store" }).Fix
Append a timestamp query parameter to every registry request in the userscript transport.
GM_xmlhttpRequestexposes no fetch cache options, and this is equivalent for our purpose: jsDelivr ignores query strings when resolving content (verified live:index.json?_=...returns the current revision), while the browser keys its HTTP cache by the full URL, so each check hits the network.Verification
pnpm format:check,pnpm lint:check(no new warnings),pnpm typecheck,pnpm build:userscriptall passophel.user.jsconfirmed to contain the cache-busting parameterNotes