Static assets get no configurable headers on native Cloudflare deploys of framework apps
Les mainteneurs répondent en général sous 1 jour
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 50/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript, vite
- Domaine
- cloud
Piste de recherche
Start by tracing uploadAssets, readGeneratedAssetHeaders, and planAssetWorkerBypass for native Cloudflare deploys, then compare their behavior with the TanStack Start asset configuration described here. Check or add coverage for user-authored _headers and fingerprinted assets; done means the reported cache headers are applied to static assets, or the docs accurately describe the limitation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Summary
A TanStack Start app deployed with void deploy --platform cloudflare serves its static assets without any configurable headers:
- A
public/_headersfile is copied todist/client/_headers, but it never applies in production.uploadAssetsignores/_headers, andreadGeneratedAssetHeadersonly sends a file whose first line is Void's generated marker ("A user-authored_headersis not sent on this path"). - Void's own immutable caching for fingerprinted bundles never runs either.
planAssetWorkerBypassonly applies when the builtwrangler.jsonhasassets.run_worker_first: ["/**"], and the TanStack Start build has only"assets": { "directory": "../client" }. With the_headersfile removed, the build generates no_headersat all. - As a result, hashed files under
/assets/are served with Cloudflare's defaultCache-Control: public, max-age=0, must-revalidate. Browsers revalidate every JS and CSS chunk on every page view.
This contradicts two docs pages:
guide/edge/static-assets.md("Native Cloudflare deployments"): "Withvoid deploy --platform cloudflare, generated JavaScript bundles with content fingerprints receive immutable caching."guide/edge/headers.md("Framework_headersfiles"): "Void reads_headersfiles produced by supported frameworks."
Reproduction
[email protected],@tanstack/[email protected], Vite 8, deployed withvoid deploy --platform cloudflarevoid.config.tssetscloudflare.cache.enabled, a custom domain route, a D1 binding and noroutingoptionspublic/_headers:/assets/* Cache-Control: public, max-age=31536000, immutable- After deploy,
curl -sI https://<site>/assets/<hashed>.jsshowscache-control: public, max-age=0, must-revalidate. CSS is the same.
I also tried routing.headers in void.config.ts ('/assets/*': ['Cache-Control: public, max-age=31536000, immutable']). In the local preview (vite preview in workerd), assets still came back with max-age=0, must-revalidate. I didn't deploy that variant, since the assets are served without starting the Worker, so I don't expect the rules to reach them.
Expected
One of these, for framework apps on native Cloudflare deploys:
- send a user-authored
_headerswith the asset upload (as Wrangler does), - generate the immutable
_headersfor fingerprinted files even withoutrun_worker_first, or - apply
routing.headersto static assets.
Failing those, the docs should say framework apps on --platform cloudflare get no asset headers.
Workaround
A Response Header Transform Rule on the zone that sets Cache-Control: public, max-age=31536000, immutable for a 200 under /assets/.
- Langage dominant
- TypeScript
- Étoiles
- 627
- Forks
- 66
- Merge moyen
- 13 h 57 min
- PR mergées (30 j)
- 194
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de voidzero-dev/void
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
voidzero-dev/void#677 ·
Les mainteneurs répondent en général sous 1 jour
-
Export a guard for `VoidActionError` at every statusPeut-être pris @karthickeyan-dev l’a pris aujourd’hui. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 78/100
voidzero-dev/void#714 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 3/5 1-2 jours Accessibilité débutants 72/100
voidzero-dev/void#713 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
`@void/solid`: `useParams()` keeps the first page's params after client-side navigationPeut-être pris @yujiym l’a pris aujourd’hui. Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 20/100
voidzero-dev/void#708 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 28/100
voidzero-dev/void#692 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de voidzero-dev/void
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Open-Earth-Foundation/CityCatalyst#3399 ·
Les mainteneurs répondent en général sous 2 jours
-
userReport
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
nkprasad12/morcus-net#631 ·
Les mainteneurs répondent en général sous 1 jour
-
fix(app): fail closed if GetGeneralSetting fails during initializationPeut-être pris @kalavt l’a pris aujourd’hui. Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
nekko-labs/nekko-agent#1756 ·
Les mainteneurs répondent en général sous 1 jour
-
needs-area-label
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
Les mainteneurs répondent en général sous 2 jours