Web image serves index.html without Cache-Control and answers missing assets with index.html, so the app loads blank after an upgrade
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 79/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- docker, typescript
Direzione di ricerca
Inizia da apps/web/Caddyfile e dai passaggi per riprodurre il problema nell’issue; identificano i comportamenti delle intestazioni di cache e degli asset mancanti da verificare. Compila ed esegui l’immagine web con docker compose up -d web caddy, quindi usa i controlli curl -I indicati per / e un percorso /assets/ inesistente. Il lavoro è completato quando il punto di ingresso dell’app è stato convalidato di nuovo e gli asset mancanti restituiscono 404; verifica che gli asset con hash mantengano una cache immutabile di lunga durata se implementi la configurazione suggerita.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
After an upgrade, the web app can load a blank page for returning users. The web image's Caddy serves index.html with Last-Modified and ETag but no Cache-Control. Browsers therefore cache it heuristically: RFC 9111 §4.2.2 allows a response to be treated as fresh for a fraction of its age, typically 10% of the time since Last-Modified. index.html is rewritten by import-meta-env when the container starts, so a web container that has been running for 30 days hands out an index.html that browsers may reuse for about 3 days without asking the server. Once a new image is deployed, a user who opens the app from a bookmark gets the old cached index.html. Its <script type="module" src="/assets/index-<old hash>.js"> no longer exists in the new image. try_files {path} /index.html then answers that request with 200 text/html, the browser refuses to run HTML as a module, and the page stays blank until the heuristic expires or the user force-reloads. The same fallback breaks any tab left open across an upgrade. Route chunks are code-split (autoCodeSplitting: true), so the next navigation imports an old chunk and gets HTML back instead of a 404. #936 tracks the same caching problem for the playground image. This issue is the clinician-facing web image.
Where
apps/web/Caddyfile:1-6:
:80 {
root * /srv
encode gzip zstd
try_files {path} /index.html
file_server
}
apps/web/Dockerfile:30 rewrites index.html at every container start:
CMD [ "sh", "-c", "import-meta-env -x .env.public -p index.html && caddy run --config /etc/caddy/Caddyfile --adapter caddyfile" ]
Reproduce
- Run
caddy:2.7-alpinewithapps/web/Caddyfileover a/srvcontainingindex.htmlandassets/index-NEW.js. - Run
curl -I /andcurl -I /assets/index-OLD.js.
Actual (verified locally): / returns 200 with Last-Modified and ETag and no Cache-Control. /assets/index-OLD.js, which does not exist, returns 200 Content-Type: text/html with the body of index.html.
Expected: index.html is sent with Cache-Control: no-cache, so every navigation revalidates it, and a missing /assets/* file returns 404.
Tests
No unit or Playwright test runs the production Caddy image. The e2e suite drives the Vite dev server. Verify the fix with the curl checks above against the built image, using docker compose up -d web caddy and curl -I http://localhost:$APP_PORT/ and /assets/does-not-exist.js.
Suggested fix
In apps/web/Caddyfile, give /assets/* its own handle with file_server and no try_files fallback, and set header Cache-Control "public, max-age=31536000, immutable" there, since those files are content-hashed. In the SPA fallback handle, set header Cache-Control "no-cache" so index.html is always revalidated. With the 404 in place, apps/web can also listen for Vite's vite:preloadError and reload, which covers tabs left open across an upgrade.
- Lingua principale
- TypeScript
- Stelle
- 119
- Fork
- 19
- Merge medio
- 18h 50m
- PR unite (30g)
- 36
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DouglasNeuroInformatics/OpenDataCapture
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
DouglasNeuroInformatics/OpenDataCapture#1813 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
DouglasNeuroInformatics/OpenDataCapture#1812 ·
I maintainer di solito rispondono entro 1 giorno
-
Area: Playground Bug Difficulty: Low Good First Issue Priority: Low
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
DouglasNeuroInformatics/OpenDataCapture#1805 ·
I maintainer di solito rispondono entro 1 giorno
-
Area: Instruments Bug Difficulty: Low Priority: Low
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
DouglasNeuroInformatics/OpenDataCapture#1801 ·
I maintainer di solito rispondono entro 1 giorno
-
Area: Instruments Bug Difficulty: Low Good First Issue Priority: Low
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
DouglasNeuroInformatics/OpenDataCapture#1800 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di DouglasNeuroInformatics/OpenDataCapture
Issue simili
-
area:desktop bug documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
anthropics/claude-code#104801 ·
I maintainer di solito rispondono entro 1 giorno
-
Add: Halloween Non Stop SDApertacheck:passed streams:add
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
spudly/design-system#110 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: REST API URL starting with "http" but no scheme (e.g. httpbin.org/get) is not given an http:// prefixForse già presa @ItsDeadlyProgrammer l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
appsmithorg/appsmith#42471 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni