amazon-web-services - services - aws login

Cómo hacer que CloudFront nunca almacene en caché index.html en el bucket de S3

Question

Tengo una aplicación React alojada en un cubo S3. El código se minimiza mediante la yarn build (es una aplicación basada en crear, reaccionar y crear). La carpeta de build ve algo como:

build
├── asset-manifest.json
├── favicon.ico
├── images
│   ├── map-background.png
│   └── robot-icon.svg
├── index.html
├── js
│   ├── fontawesome.js
│   ├── packs
│   │   ├── brands.js
│   │   ├── light.js
│   │   ├── regular.js
│   │   └── solid.js
│   └── README.md
├── service-worker.js
└── static
├── css
│   ├── main.bf27c1d9.css
│   └── main.bf27c1d9.css.map
└── js
├── main.8d11d7ab.js
└── main.8d11d7ab.js.map

Nunca quiero que index.html en caché, porque si actualizo el código (causando que el sufijo hexadecimal en main.*.js actualice), necesito que la próxima visita del usuario <script src> cambio en el index.html <script src> index.html para apuntar al código actualizado.

En CloudFront, parece que solo puedo excluir rutas, y la exclusión de "/" no parece funcionar correctamente. Me estoy comportando de forma extraña cuando cambio el código, y si pulso actualizar, lo veo, pero si salgo de Chrome y vuelvo, veo un código muy desactualizado por alguna razón.

No quiero tener que activar una invalidación en cada versión de código (a través de CodeBuild). ¿Hay alguna otra manera? Creo que uno de los desafíos es que, dado que se trata de una aplicación que utiliza React Router, tengo que hacer algunos trucos configurando el documento de error en index.html y forzando un estado HTTP 200 en lugar de 403.

Answer 1

Aquí está el comando que ejecuté para configurar el control de caché en mi archivo index.html después de cargar nuevos archivos en s3 e invalidar Cloudfront:

aws s3 cp s3://bucket/index.html s3://bucket/index.html --metadata-directive REPLACE --cache-control max-age=0

Answer 2

Si nunca desea que index.html en caché, configure el encabezado Cache-Control: max-age=0 solo en ese archivo. CloudFront realizará una solicitud a su grupo S3 de origen en cada solicitud, pero parece que este es el comportamiento deseado.

Si desea establecer tiempos de caducidad más largos e invalidar el caché de CloudFront manualmente, puede usar un * o /* como su ruta de invalidación (no / como ha mencionado). Sin embargo, esto puede demorar hasta 15 minutos para que todos los nodos de borde de CloudFront de todo el mundo reflejen los cambios en su origen.