Skip to content

Cache proxied embed tracks until the archive changes - #873

Merged
nulltask merged 1 commit into
develfrom
fix/embed-track-http-cache
Oct 31, 2026
Merged

nulltask merged 1 commit into
develfrom
fix/embed-track-http-cache

Conversation

@nulltask

Copy link
Copy Markdown
Owner

Summary

  • An embed ?track= (and the player's ?music=) archive from another origin was downloaded in full on every load: /__url-load-proxy answered cache-control: no-store and dropped the host's validators.
  • The proxy (moved to packages/worker-play/src/url-load-proxy.ts) now answers no-cache, passes the upstream's ETag / Last-Modified back, and forwards the browser's If-None-Match / If-Modified-Since. The browser keeps the archive and revalidates it on each load; an unchanged archive comes back as a bodiless 304. A host that sends no validator is still downloaded every time.
  • Only those two conditional headers are forwarded upstream (no cookies or other browser headers).
  • Same-origin tracks are served by Workers Static Assets, which already send an ETag, so they need no change.
  • Docs (EN/JA) and a @be-music/worker-play changeset.

Tests

  • pnpm run check
  • vp test run packages/worker-play (new url-load-proxy.test.ts: validators pass through, 304 on an unchanged archive, 200 on a changed one, no other headers forwarded, method / target refusals)

🤖 Generated with Claude Code

… of downloading them again

/__url-load-proxy answered no-store and dropped the upstream's validators, so every embed ?track= (and player ?music=) load from another origin downloaded the whole archive. Move the proxy into url-load-proxy.ts, answer no-cache, and pass ETag / Last-Modified and If-None-Match / If-Modified-Since through, so an unchanged archive comes back as a 304.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant