Amazon CloudFront 未针对未更改的静态内容始终返回 304（未修改）？

Posted 2023-03-27

【中文标题】Amazon CloudFront 未针对未更改的静态内容始终返回 304（未修改）？

【英文标题】：Amazon CloudFront not consistently returning 304 (Not Modified) for unchanged static content?

【发布时间】：2014-06-06 23:53:21

【问题描述】：

EC2 Web 服务器网格在 ELB 负载均衡器后面运行。 ELB 位于 Amazon 的 CloudFront 内容交付网络的背后。内容交付网络对我来说非常陌生。我的理解是 CloudFront 应该通过在其“边缘”缓存静态内容来提高性能。但这不是正在发生的事情。

考虑我的 EC2 实例，其内容的生命周期应始终为五分钟。对于静态内容，这通常意味着在我的 web.config 文件中声明以下内容：

<staticContent>
    <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="00.00:05:00"/>
</staticContent>

...对于动态的东西，它通常意味着对 HttpResponse 对象执行以下命令：

resp.Cache.SetCacheability(HttpCacheability.Public);
resp.Cache.SetMaxAge(TimeSpan.FromMinutes(5));

以此为背景...

当我的浏览器直接点击 ELB 时，一切正常。 Firebug 始终显示，对于存在于浏览器缓存中的内容返回 304（未修改），已超过 5 分钟到期，但在服务器上尚未更改。以下是下载 defs.js 的响应标头，例如：

HTTP/1.1 304 Not Modified
Accept-Ranges: bytes
Cache-Control: public,max-age=300
Date: Tue, 22 Apr 2014 13:54:16 GMT
Etag: "0152435d158cf1:0"
Last-Modified: Tue, 15 Apr 2014 17:36:18 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Connection: keep-alive

IIS 正确地看到该文件自 4 月 15 日以来没有更改并返回 304。

但是看看通过 CloudFront 抓取文件时会发生什么。

HTTP/1.1 200 OK
Content-Type: application/x-javascript
Content-Length: 205
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: public,max-age=300
Date: Tue, 22 Apr 2014 14:07:33 GMT
Etag: "0152435d158cf1:0"
Last-Modified: Tue, 15 Apr 2014 17:36:18 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Age: 16
X-Cache: Hit from cloudfront
Via: 1.1 0f140ef1be762325ad24a7167aa57e65.cloudfront.net (CloudFront)
X-Amz-Cf-Id: Evfdhs-pxFojnzkQWuG-Ubp6B2TC5xbunhavG8ivXURdp2fw_noXjw==

在这种情况下，CloudFront 会强制浏览器再次下载整个文件，尽管您可以看到：

(a) 它知道文件自 4 月 15 日以来没有被修改（参见 Last-Modified 标题），并且 (b) CloudFront 手头确实有文件的缓存副本（请参阅 X-Cache 标头）

也许您想知道我的浏览器是否正在发送有效的 If-Modified-Since 标头。的确是。以下是请求标头：

GET /code/shared/defs.js HTTP/1.1
Host: d2fn6fv5a0cu3b.cloudfront.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://d2fn6fv5a0cu3b.cloudfront.net/
Connection: keep-alive
If-Modified-Since: Tue, 15 Apr 2014 17:36:18 GMT
If-None-Match: "0152435d158cf1:0"
Cache-Control: max-age=0

这是一个奇怪的情况。如果我只是坐在浏览器前并继续执行页面重新加载 (Cmd-R)，可能大约一半的时间 CloudFront 会正确返回 304，而另一半时间它会错误地返回 200 以及所有内容.在与页面交互之前等待 5 分钟到期，主要是 200 和只有少数 304。这种奇怪的行为适用于 html 页面上引用的所有文件（.css、.js、.png 等）以及包含的 HTML 页面本身。我知道我的应用程序编码正确，因为如上所述，直接访问 ELB 而不通过 CloudFront 会导致预期的 304 结果。有什么想法吗？

【参考方案1】：

答案是在一段看似无关的亚马逊文档中写的一个晦涩的句子中找到的：

When you configure CloudFront to forward cookies to your origin [...] If-Modified-Since and If-None-Match conditional requests are not supported.

很奇怪，但实际情况确实要糟糕得多；并不是将 cookie 转发到您的源服务器会禁用条件请求，而是会禁用它们有时——以至于 HTTP 结果代码（304 与 200）实际上是随机的。

请务必注意，即使您根本不使用 Cookie，您也会被这种奇怪的行为所困扰。如下图所示，将 Forward Cookies 下拉菜单设置为“无”仍然是绝对必要的：

将设置切换为“无”修复了我原来帖子中描述的错误行为。

这个解决方案给您带来了另一个问题。您告诉 CloudFront 在将请求转发到您的源之前完全删除所有 cookie。但是您的源服务器可能需要这些 cookie。此外，如果您使用 ELB（负载均衡器）作为源，ELB 用来维持粘性会话的关键 cookie 将被完全删除。不好。

cookie 剥离问题的解决方案取决于您网站的组织方式。就我而言，只有在将 AJAX 数据发布到 myDomain.com/ajax/ 时才需要传输 cookie（与会话相关或其他）。因为所有依赖于 cookie 的 URL 都属于 ajax/* 类别，所以必须为该路径创建一个新的行为规则，并且在该规则中，并且仅在该规则中，转发 Cookie 下拉菜单设置为“全部”而不是“没有。”

原来如此。希望这对某人有所帮助。

【讨论】：

该死的 AWS，现在我需要从基于 cookie 的身份验证切换到 JWT。 >:(非常感谢你！