Skip to content

Redirect assets through jsDelivr with GitHub raw fallback#1270

Merged
Majorfi merged 2 commits into
mainfrom
feat/jsdelivr-fallback
Jul 10, 2026
Merged

Redirect assets through jsDelivr with GitHub raw fallback#1270
Majorfi merged 2 commits into
mainfrom
feat/jsdelivr-fallback

Conversation

@Majorfi

@Majorfi Majorfi commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Summary

Implements CDN-based asset delivery through jsDelivr with automatic fallback to GitHub raw content. Fallback handling now uses HTTP redirects instead of server-side fetching, reducing server load. Adds a workflow to purge jsDelivr cache when needed.

What changed

  • Added cdnFallback.go with logic to redirect asset requests through jsDelivr
  • Implemented GitHub raw content fallback for when jsDelivr is unavailable
  • Changed fallback URL handling from server-side fetches to HTTP 302 redirects
  • Added purge-jsdelivr.yml workflow for cache invalidation
  • Refactored serveToken.go to remove server-side fallback fetching logic
  • Updated serveChain.go to wire in the new CDN fallback handler

Risks

  • Clients must support following HTTP redirects; some integrations may fail if they don't
  • jsDelivr availability becomes a critical dependency; outages require GitHub fallback
  • CDN caching may delay propagation of updated assets
  • External redirects could add latency for some geographic regions

Test plan

  • Verify assets return proper 302 redirects to jsDelivr URLs
  • Test fallback redirect chain resolves to GitHub raw content
  • Simulate jsDelivr unavailability and confirm fallback is triggered
  • Verify the purge-jsdelivr workflow successfully clears CDN cache
  • Monitor asset delivery latency and redirect chain resolution
  • Test with various HTTP clients to ensure redirect handling is reliable

Docs impact

Documentation should be updated to explain the new CDN redirect behavior, fallback mechanism, and how to manually trigger cache purges via the new workflow.

Breaking changes

Fallback asset delivery now uses HTTP redirects instead of server-side fetching. Clients that don't follow redirects will fail to retrieve assets through the fallback path.

Majorfi added 2 commits July 10, 2026 16:01
jsDelivr serves the same files multi-CDN with 7-day client caching,
versus 5 minutes on raw.githubusercontent.com. A 30s health check
promotes jsDelivr after two consecutive successes and falls back to
GitHub raw after two consecutive failures; FORCE_GITHUB_CDN=true pins
the legacy behavior. Redirects switch from 308 to 307 with a 300s
Cache-Control so a CDN switch propagates within minutes instead of
being pinned forever by browser-cached permanent redirects.

A workflow purges changed files from the jsDelivr cache on merge so
freshly added logos are available immediately.
The fallback query param let the daemon http.Get an arbitrary
client-supplied URL and stream the bytes back on our own origin. That
was a server-side request forgery vector (probing the host's internal
network) and, if the UI is ever served from this same domain, a
reflected same-origin XSS sink (an attacker SVG rendered as a
top-level document on our origin).

Redirect the browser to the URL instead: the daemon makes no outbound
request, and the fallback image renders on its own origin, never ours.
Restricted to http(s) so the Location cannot carry a javascript: or
data: scheme. The fallback=true path (static built-in images) is
unchanged.
@vercel

vercel Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
token-assets Building Building Preview, Comment Jul 10, 2026 3:40pm

Request Review

@Majorfi Majorfi merged commit bbfacb9 into main Jul 10, 2026
6 of 7 checks passed
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