Skip to content

fix(server): add Cache-Control headers to static assets#27934

Open
BYK wants to merge 1 commit into
anomalyco:devfrom
BYK:fix/static-asset-cache-headers
Open

fix(server): add Cache-Control headers to static assets#27934
BYK wants to merge 1 commit into
anomalyco:devfrom
BYK:fix/static-asset-cache-headers

Conversation

@BYK
Copy link
Copy Markdown
Contributor

@BYK BYK commented May 16, 2026

Issue for this PR

Closes #27931

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Adds Cache-Control headers to the embedded web UI asset responses in server/shared/ui.ts:

  • Hashed assets (Vite content-hashed filenames like index-abc123.js): public, max-age=31536000, immutable — these filenames change when content changes, so they can be cached indefinitely.
  • HTML: no-cache — always revalidate to pick up new asset references.
  • Other static files (favicons, manifest, etc.): public, max-age=3600 — reasonable 1hr cache.

A regex detects Vite's content-hash pattern (- or . followed by 8+ hex chars before the extension).

How did you verify your code works?

Tested locally by checking response headers on static assets served by the embedded web UI. Verified hashed assets get immutable, HTML gets no-cache, and other files get 1hr cache.

Screenshots / recordings

N/A — response header change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

Hashed assets (Vite content-hashed filenames) get immutable/1yr cache.
HTML gets no-cache to always revalidate for fresh asset references.
Other static files (favicons, manifest) get 1hr cache.
@github-actions
Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

One potentially related PR found:

PR #27936: fix(app): add service worker for cache-first static asset loading
#27936

Why it might be related: This PR also addresses static asset caching strategy. While PR #27934 focuses on Cache-Control headers at the server level, PR #27936 appears to implement client-side caching via service worker. These could be complementary approaches or potentially address overlapping concerns in the caching strategy. Worth reviewing to ensure they work together cohesively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Static assets served without Cache-Control headers

1 participant