Cloudflare Workers 站点中的缓存控制标头

Question

我只是用 Hugo 创建的静态站点测试 Workers 站点。它已经存在，因此我使用 docs\xe2\x80\x99 说明来调整现有站点。和文件cache-control的标题全部显示为，与我基于https://support.cloudflare.com/hc/en-us/articles/200172516#h_a01982d4-d5b6-4744-bb9b-的预期相反a71da62c160a。有问题的工人网站是https://hosts-test-hugo.brycewray.workers.dev/。woff2cssno-cache

\n

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

\n

\n

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

\n

\n

该站点是否需要有一个自定义域 \xe2\x80\x94 即，而不是 \xe2\x80\x9c.workers.dev\xe2\x80\x9d URL \xe2\x80\x94 才能进行正常缓存行为？这还有关系吗？

\n

[注：我在此发布此内容是因为我在Cloudflare 社区论坛或Cloudflare subreddit \xe2\x80 \x94 上均未能成功获得响应，希望在这里能获得更好的结果。]

\n

Answer 1

再次感谢 Cloudflare\xe2\x80\x99s Kenton Varda 在这里的回答，没有它我\xe2\x80\x99d 就完全陷入困境了。我还感谢Brian Li单独提供的额外且同样有价值的帮助。

\n

添加以下内容以供其他人使用\xc2\xa0.\xc2\xa0.\xc2\xa0。

\n

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

\n

  options.cacheControl = {\n    browserTTL: 0,\n    edgeTTL: 0,\n    bypassCache: false // default\n  }\n\n  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))$/\n\n  if(url.pathname.match(filesRegex)) {\n    options.cacheControl.edgeTTL = 2592000\n    options.cacheControl.browserTTL = 2592000\n  }\n

\n

如果您查看链接的问题评论并想知道 \xe2\x80\x99 有什么不同：唯一的事情是我从扩展列表中删除了html（并且，为了安全起见）。htm因此，我的 Worker 站点\xe2\x80\x99s HTML 的缓存为零，而每个 CSS、字体或图像文件的一个月cache-control设置 \xe2\x80\x94 正是所需的结果。注意：绝大多数 site\xe2\x80\x99s 图像都托管在其他地方，但我仍然托管少量的网站图标和后备图像。

\n

Answer 2

默认情况下，Workers Sites 不提供Cache-Control标头，但您可以自定义它来提供标头。（编辑澄清：默认情况下，Workers 站点缓存在 Cloudflare 的边缘，并支持“etag”进行重新验证。标Cache-Control头控制它们是否也缓存在浏览器中，而不需要重新验证。）

请注意，Workers Sites 的工作方式与将 Cloudflare 与经典源服务器结合使用非常不同。如果您正在阅读有关 Cloudflare 上的缓存的内容，但它没有具体提及 Workers Sites，那么它可能不适用于 Workers Sites。

借助 Workers Sites，您的站点由 Cloudflare Worker 提供服务 - 直接在 Cloudflare 服务器上运行的代码。因此，Cloudflare 背后没有“原始”服务器，并且 Cloudflare 的缓存无法以正常方式工作。Worker 代码完全负责提供内容，包括设置任何标头，例如Cache-Control.

事实上，当您使用 创建新的 Workers Sites 项目时wrangler，会为您生成该 Worker 的代码 - 但您可以编辑它！您可以自定义代码，做任何您想做的事情。Worker 的代码可以在您的项目目录下找到workers-site/index.js。代码看起来像这样——事实上，它被初始化为来自 GitHub 的该文件的副本。

@cloudflare/kv-asset-handler该工作代码依赖于调用来完成大部分工作的库（npm 模块） 。可以通过选项自cacheControl定义该库以各种方式处理缓存。

但是你在哪里设置这个选项呢？好吧，在你的工人代码中！

打开并寻找如下所示的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 代码来自定义其网站服务方式的人们而设计的。对于那些对编写代码不感兴趣的人，您将仅限于默认行为，这可能适合也可能不适合您的需求。