I'm deploying a Single Page Application (SPA) on AWS S3 and CloudFront, and I'm facing an issue with caching that leads to outdated versions of the application being loaded.

Problem:

1. Browsers like Chrome and Edge:

   • When users open the app via bookmarks, the browser loads index.html directly from the disk cache without making a HEAD or GET request to check for updates.
   • This happens when the index.html file doesn't have the correct Cache-Control headers.
   • As a result, old JavaScript and CSS files (referenced in the outdated index.html) are loaded, causing the application to run an older version.

2. Redirect Configuration:

   • I currently have a CloudFront custom error response set up:
     • 403 errors are mapped to 200, and index.html is served.
     • This is done to ensure deep links in the SPA work correctly.
   • However, this may be affecting how caching and updates are handled for index.html.

3. Requirements:

   • index.html: Should always check for updates. Headers like Cache-Control: no-cache or max-age=0, must-revalidate should force the browser to revalidate it.
   • Static assets (.js, .css, etc.): These are hashed (e.g., main.abc123.js), so they can be cached long-term (Cache-Control: public, max-age=31536000, immutable).

---

Current Setup:

• S3: Stores index.html and versioned assets (js/css files with hashes).
• CloudFront:
  • Default Cache Behavior for all files (/*). No cache-control header modification.
  • Custom error response: 403 → 200, returning index.html (lambda does not trigger here i think).
  • current temp solution: Added a Viewer response lambda@edge to add Cache-Control: no-cache for text/html files. Added Viewer request lambda@edge, to redirect anything without extension (not asset) to index.html. Works but i think there should be a better solution.

---

Questions:

1. Is it true that Chrome/Edge bookmarks skip checking for updates (e.g., ETag) if no Cache-Control header is set and load files directly from disk cache?
2. Does the useful SPA "403 → 200, → index.html" error response affect caching behavior, and if so, how can I improve it? (looks like there is no labmda@edge "viewer-response" trigger on it, but the Default(*) behavior is there)
3. What’s the best caching configuration to ensure the app always checks for updates (e.g., ETag/header) for index.html but keeps static assets cached long-term?

---

Thx for help!

I'm deploying a Single Page Application (SPA) on AWS S3 and CloudFront, and I'm facing an issue with caching that leads to outdated versions of the application being loaded.

Problem:

1. Browsers like Chrome and Edge:

   • When users open the app via bookmarks, the browser loads index.html directly from the disk cache without making a HEAD or GET request to check for updates.
   • This happens when the index.html file doesn't have the correct Cache-Control headers.
   • As a result, old JavaScript and CSS files (referenced in the outdated index.html) are loaded, causing the application to run an older version.

2. Redirect Configuration:

   • I currently have a CloudFront custom error response set up:
     • 403 errors are mapped to 200, and index.html is served.
     • This is done to ensure deep links in the SPA work correctly.
   • However, this may be affecting how caching and updates are handled for index.html.

3. Requirements:

   • index.html: Should always check for updates. Headers like Cache-Control: no-cache or max-age=0, must-revalidate should force the browser to revalidate it.
   • Static assets (.js, .css, etc.): These are hashed (e.g., main.abc123.js), so they can be cached long-term (Cache-Control: public, max-age=31536000, immutable).

---

Current Setup:

• S3: Stores index.html and versioned assets (js/css files with hashes).
• CloudFront:
  • Default Cache Behavior for all files (/*). No cache-control header modification.
  • Custom error response: 403 → 200, returning index.html (lambda does not trigger here i think).
  • current temp solution: Added a Viewer response lambda@edge to add Cache-Control: no-cache for text/html files. Added Viewer request lambda@edge, to redirect anything without extension (not asset) to index.html. Works but i think there should be a better solution.

---

Questions:

1. Is it true that Chrome/Edge bookmarks skip checking for updates (e.g., ETag) if no Cache-Control header is set and load files directly from disk cache?
2. Does the useful SPA "403 → 200, → index.html" error response affect caching behavior, and if so, how can I improve it? (looks like there is no labmda@edge "viewer-response" trigger on it, but the Default(*) behavior is there)
3. What’s the best caching configuration to ensure the app always checks for updates (e.g., ETag/header) for index.html but keeps static assets cached long-term?

---

Thx for help!

• amazon-web-services
• amazon-s3
• caching
• single-page-application
• amazon-cloudfront

Share Improve this question Follow edited Jan 23 at 9:50 ya_dimon asked Jan 22 at 23:08 ya_dimonya_dimon 3,85255 gold badges3434 silver badges4444 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

Question 1

Is it true that Chrome/Edge bookmarks skip checking for updates (e.g., ETag) if no Cache-Control header is set and load files directly from disk cache?

As far as I know, Cache-Control supersedes ETag. Cache-Control max-age tells the browser not even to attempt checking for ETag. However once the content is stale (as determined by the max-age), browsers can request the servers by providing its cached ETag value. This helps the server because if the ETag has not changed, the server may choose not to return the full-sized content and instead just say "304 Not Modified".

Question 2

Does the 403 → 200 error response affect caching behavior, and if so, how can I improve it?

It does affect caching behavior, but isn't it a single page application? In other words, index.html is always involved anyway. And the caching is still subject to Cache Control headers. So you can still use max-age. I don't think this is an issue.

Question 3

What’s the best caching configuration to ensure the app always checks for updates (e.g., ETag/header) for index.html but keeps static assets cached long-term?

It seems like you already know this, use Cache Control headers to control browser behavior. You can configure different max-age for different assets. And on the CloudFront side, just run invalidate cache whenever you have an updated version of index.html.