Cloudflares Worker 緩存 API 出現問題

Question

我現在花了無數個小時試圖獲取緩存 API 來緩存一個簡單的請求。 我讓它在兩者之間工作過一次，但忘記在緩存鍵中添加一些東西，現在它不再工作了。 不用說， cache.put()沒有返回值來指定請求是否實際被緩存並不能完全幫助我，我只能反復試驗。 有人可以提示我做錯了什么以及實際需要什么嗎？ 我現在已經閱讀了所有文檔超過 3 次，我很茫然……

值得注意的是，這個 REST 端點設置了pragma: no-cache和其他所有與 no-cache 相關的緩存，但我想強制緩存響應，這就是為什么我試圖在緩存之前完全重寫標題，但它仍然無法正常工作（不匹配或不存儲，沒人知道......）

async function apiTest(token, url) {
    let apiCache = await caches.open("apiResponses");
    let request = new Request(
        new URL("https://api.mysite.com/api/"+url),
        {
            headers: {
                "Authorization": "Bearer "+token,
            }
        }
    )
    // Check if the response is already in the cloudflare cache
    let response = await apiCache.match(request);
    if (response) {
        console.log("Serving from cache");
    }
    if (!response) {
        // if not, ask the origin if the permission is granted
        response = await fetch(request);
        // cache response in cloudflare cache
        response = new Response(response.body, {
            status: response.status,
            statusText: response.statusText,
            headers: {
                "Cache-Control": "max-age=900",
                "Content-Type": response.headers.get("Content-Type"),
            }
        });
        await apiCache.put(request, response.clone());
    }
    return response;
}

在此先感謝您的幫助，我首先在 Cloudflare 社區上提出了相同的問題，但在 2 周內沒有收到答復

Answer 1

這可能與您使用caches.default相關，而不是使用caches.open("whatever")打開私有緩存。 當您使用caches.default時，您將共享fetch()本身使用的同一個緩存。 因此，當您的工作人員運行時，您的工作人員檢查緩存，然后fetch()檢查緩存，然后fetch()稍后寫入緩存，然后您的工作人員也寫入相同的緩存條目。 由於寫入操作特別是異步發生的（當響應流通過時），它們很可能重疊並且緩存變得混亂並將它們全部扔掉。

為避免這種情況，您應該打開一個私有緩存命名空間。 所以，替換這一行：

let cache = caches.default;

和：

let cache = await caches.open("whatever");

（這個await總是立即完成；它只是因為緩存 API 標准堅持認為這個方法是異步的。）

這樣，您正在讀取和寫入與fetch()本身讀取/寫入的緩存條目完全分開的緩存條目。

caches.default的用例是當您有意操作fetch()也將使用的緩存條目時，但我認為您不需要在此處執行此操作。

---

編輯：根據下面的對話，我現在懷疑Authorization header 的存在導致緩存拒絕存儲響應。 但是，使用自定義緩存命名空間（如上所述）意味着您可以使用沒有 header 的Request安全地緩存值，因為您知道緩存的響應只能由 Worker 通過緩存 API 訪問。 聽起來這種方法適用於您的情況。