問題描述
當您的應用服務器託管在不同的雲服務上時，如何安全地從 Firebase 託管上的 CDN 緩存中受益 (How to safely benefit from CDN caching on Firebase Hosting when your app's server is hosted on a different Cloud service)
我已經長期緩存我的靜態資產，例如：css、圖像、js 文件等。由於這些文件在我的構建過程中都得到 content‑hash ids，所以我就是這樣對待的它們的緩存方式：
// STATIC FILES LIKE IMAGES, FONTS, CSS AND JS
Cache‑Control: "public,max‑age=31536000"
這樣我就可以獲得長達一年的客戶端和 CDN 緩存，這很棒。它工作正常。
但是我的網絡應用程序是單頁 React 應用程序，所以每當我更新它時，我的用戶從我的應用程序獲得的唯一 index.html 文件會自動變得陳舊而且沒用，因為它指向的是舊的靜態JS文件，現在已經全部更新了。
所以基本上我不能讓他們得到一個陳舊的index.html。
我還想從該文件的 CDN 緩存中獲得好處。這就是它可能變得棘手的時候。
現在，為了安全起見，這就是我正在做的事情：
// For index.html
Cache‑Control: "no‑cache, no‑store, must‑revalidate"
我正在考慮將其更改為：
// FOR index.html
Cache‑Control: "max‑age=0, s‑maxage=86400, must‑revalidate"
這樣我會得到一個1天的CDN緩存，這很好。但我仍然不想冒險提供陳舊的 index.html。
這就是 Firebase Hosting 說：
任何請求的靜態內容都會自動緩存在 CDN 上。如果您重新部署網站的內容，Firebase 託管會自動清除 CDN 中所有緩存的靜態內容，直到下一次請求。
但問題是我的服務器託管在 Cloud Run 上。Firebase Hosting 基本上 rewrite 每個請求。類似於：
firebase.json
"rewrites": [
{
"source": "**",
"run": {
"serviceId": "server",
"region": "uscentral‑1"
}
}
]
所以，每當我更新我的應用程序時，我都會將其重新部署到 Cloud Run，但我沒有運行一個新的 firebase deploy ‑‑only hosting 命令。因為在 Cloud Run 代碼的新部署之間，我的 firebase.json 文件中沒有任何變化。
QUESTION
在這種情況下添加 s‑maxage=86400 標頭是否安全？
假設 Cloud Run 上的新部署不會觸發清除CDN 緩存。我可以做些什麼來觸發它嗎？像一些 firebase deploy ‑‑only hosting:clear‑cdn 命令？
因為即使我再次運行 firebase deploy ‑‑only hosting，我'我不確定緩存的文件是否會被清除，因為我的 Firebase Hosting /public 文件夾始終是一個空文件夾。所以 Firebase Hosting 可能會“感覺”到 什麼都沒有改變。
firebase deploy ‑‑only hosting:clear‑cdn 命令？ 因為即使我再次運行 firebase deploy ‑‑only hosting，我'我不確定緩存的文件是否會被清除，因為我的 Firebase Hosting /public 文件夾始終是一個空文件夾。所以 Firebase Hosting 可能會“感覺”到 什麼都沒有改變。
firebase deploy ‑‑only hosting:clear‑cdn 命令？ 因為即使我再次運行 firebase deploy ‑‑only hosting，我'我不確定緩存的文件是否會被清除，因為我的 Firebase Hosting /public 文件夾始終是一個空文件夾。所以 Firebase Hosting 可能會“感覺”到 什麼都沒有改變。
/public 文件夾始終是一個空文件夾。所以 Firebase Hosting 可能會“感覺”到 什麼都沒有改變。 因為我的 Firebase Hosting /public 文件夾始終是一個空文件夾。所以 Firebase Hosting 可能會“感覺”到 什麼都沒有改變。參考解法
方法 1:
After a day of testing, here are the results:
If you set Cache‑Control headers that will allow for shared (CDN) caching, like public or no‑cache, your responses will be caches both on client browser and on CDN caching.
- When you re‑deploy to Cloud Run, will it clear your CDN cache automatically?
No. When you update and re‑deploy your app files to Cloud Run, those cached files on CDN will be stale and will not be automatically cleared from the CDN. So even if nothing has changed as far as Firebase Hosting is concerned, you need to run firebase deploy ‑‑only hosting again. This will make the CDN clear all of your cached files and new requests will start getting fresh data right away.
- I'm not really sure the cached files will be purged, because my Firebase Hosting /public folder is always an empty folder. So Firebase Hosting might "feel" that nothing has changed.
Even if nothing in your Firebase Hosting public folder has changed (in my case it's an empty folder) and nothing in your firebase.json has changed, it will still create a new Firebase Hosting release and it will clear your cached files from the CDN, like the doc says:
Any requested static content is automatically cached on the CDN. If you redeploy your site's content, Firebase Hosting automatically clears all your cached static content across the CDN until the next request.
Attention for dynamic content
If you have dynamic content that you'll edit through an admin UI, for example. Be aware that the CDN cache will keep stale cache of that content until it expires.
For example: CDN caches /blog/some‑post with s‑maxage of 1 day. Even if you change the content of your post dynamically, the CDN will keep the CDN for 1 full day, until it expires and it gets requested again.
(by cbdeveloper、cbdeveloper)