云flare Workers 站点中的缓存控制标头

Question

我只是在使用由Hugo创建的静态网站测试Workers网站。它已经存在，所以我使用了文档中关于适应现有网站的说明。与https://support.cloudflare.com/hc/en-us/articles/200172516#h_a01982d4-d5b6-4744-bb9b-a71da62c160a相反，woff2和css文件的cache-control标头都显示为no-cache，这与我的预期不符。涉及的Workers网站是https://hosts-test-hugo.brycewray.workers.dev/。

我在https://levelup.gitconnected.com/use-cloudflare-javascript-workers-to-deploy-you-static-generated-site-ssg-1c518e078646上找到了以下内容，但不知道它是否相关：

Cloudflare Worker是一段JavaScript代码，每当您访问由Cloudflare代理的网站上的特定路由时都会运行。该代码在每个请求 到达 Cloudflare缓存之前执行。这意味着Worker响应不会被缓存（尽管工作人员对其他Web服务发出的请求可能会使用适当的缓存标头进行缓存）。

该网站需要具有自定义域名，即“.workers.dev” URL之外的域名，才能具有正常的缓存行为吗？这是否相关？

[注意：我在这里发布是因为我在Cloudflare社区论坛或Cloudflare subreddit上都没有得到回应，希望在这里能得到更好的结果。]

- Bryce Wray

---

我尝试访问您的网站，但并未在任何响应中看到“cache-control: no-cache”。特别是CSS和Woff2文件似乎根本没有缓存控制头，但是cf-cache-status显示它们正在被Cloudflare缓存。您在什么情况下看到“no-cache”？ - Kenton Varda

@KentonVarda 我在Chrome DevTools的请求标头中看到了这个。我想问题是为什么响应标头下没有cache-control标头。我在其他我知道是Workers站点上看到类似的结果。然而：经过比我已经做过的许多小时的额外搜索，我现在在CF网站内外找到了更多解释得更好的信息。感谢您的回复，先生。 - Bryce Wray

Answer 1

感谢 Cloudflare 的 Kenton Varda 在此处提供的答案，否则我将一脸懵逼。我还要感谢 Brian Li 提供的额外帮助，同样地宝贵。

为了让其他人更容易使用，我在这里添加以下内容...

我遇到的问题是我不知道如何为大多数静态资源分配不同的cache-control值（例如一个月或2592000），同时将 HTML 设置为较小的值（例如3600或0）。几天后，我在 Cloudflare KV-Asset-Handler 存储库的 Issue #81 中的评论中找到了答案。所以，现在，在我的 Worker 的 index.js 文件中有以下代码：

  options.cacheControl = {
    browserTTL: 0,
    edgeTTL: 0,
    bypassCache: false // default
  }

  const filesRegex = /(.*\.(ac3|avi|bmp|br|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|ico|img|iso|jpeg|jpg|js|json|map|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|webp|webm|webmanifest|woff|woff2|xls|xlsx|xml|zip))$/

  if(url.pathname.match(filesRegex)) {
    options.cacheControl.edgeTTL = 2592000
    options.cacheControl.browserTTL = 2592000
  }

如果你看了那个链接的评论并想知道有什么不同之处：唯一的区别就是我从扩展名列表中删除了html（为了安全起见，也删除了htm）。结果，我的Worker网站的HTML没有缓存，而每个CSS、字体或图像文件都有一个一个月的cache-control设置——正是预期的结果。 注意：该网站绝大部分图像都托管在其他地方，但我仍然为favicon和一般回退托管了少量图像。

- Bryce Wray

---

只是为了明确，当您使用 Workers Sites 提供站点时，与在常规源服务器前使用 Cloudflare 的工作方式非常不同。我认为您的链接实际上与 Workers Sites 无关。这里似乎问题只是 Workers Sites 没有发送任何 cache-control: max-age。这对我来说实际上就像是 Workers Sites 中的一个错误。您可以编辑 workers-site/index.js 中的 JavaScript 以使其添加缓存控制标头，但我们应该在默认模板中修复此问题。 - Kenton Varda

好的，看起来功能已经存在了，只是默认情况下没有启用。我会发布一个答案来说明如何启用它... - Kenton Varda

@KentonVarda 非常感谢！ - Bryce Wray

Answer 2

默认情况下，Workers Sites不会提供Cache-Control头信息，但您可以自定义以提供该信息。（编辑说明：默认情况下，Cloudflare的边缘会对Workers Sites进行缓存，并支持“ etags”进行重新验证。 Cache-Control头控制是否在浏览器中缓存它们而无需重新验证。）请注意，Workers Sites的工作方式与使用经典源服务器的Cloudflare非常不同。如果您正在阅读有关在Cloudflare上缓存的内容，但未特别提到Workers Sites，则该内容可能不适用于Workers Sites。使用Workers Sites时，您的网站是由运行在Cloudflare服务器上的Cloudflare Worker提供服务的。因此，您在Cloudflare后面没有“起源”服务器，并且Cloudflare的缓存不会以正常方式工作。Worker代码完全负责提供内容，包括设置任何头文件，例如Cache-Control。事实上，在使用wrangler创建新的Workers Sites项目时，为您生成了此Worker的代码-但允许您对其进行编辑！您可以根据需要自定义代码。Worker的代码在您的项目目录下的workers-site/index.js中找到。代码看起来像这样-实际上，它初始化为来自GitHub的该文件的副本。该Worker代码依赖于一个称为@cloudflare/kv-asset-handler的库（npm模块）来完成大部分工作。通过 cacheControl选项，可以自定义此库以处理各种缓存方式。但是，您在哪里设置此选项？ 好吧，在您的worker代码中！打开workers-site/index.js并查找类似于这样的部分：

async function handleEvent(event) {
  const url = new URL(event.request.url)
  let options = {}

  /**
   * You can add custom logic to how we fetch your assets
   * by configuring the function `mapRequestToAsset`
   */
  // options.mapRequestToAsset = handlePrefix(/^\/docs/)

该评论提到了使用 options 自定义网站服务的一种方式，但你也可以在此设置 cacheControl。尝试添加以下内容：

  options.cacheControl = {
    browserTTL: 3600      // 1 hour
  }

现在重新部署您的站点，您应该会看到资源文件带有Cache-Control: max-age=3600。当然，这意味着用户浏览器中的内容可能会被缓存长达一个小时（3600秒）；您可以选择更长或更短的时间。

请注意，如果您不是程序员，这一切可能看起来有点令人生畏。 Workers Sites 实际上是为那些想通过编辑 JavaScript 代码自定义其站点如何提供服务的人而设计的。对于不想编写代码的人来说，您将受到默认行为的限制，这可能适合您的需求，也可能不适合。

- Kenton Varda