asp.net - 对于未更改的静态内容，Amazon CloudFront 是否始终返回 304(未修改)？

Question

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(未修改)。例如，以下是下载 defs.js 的响应 header :

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 header )，并且(b) CloudFront 手头确实有该文件的缓存副本(请参阅 X-Cache header )

也许您想知道我的浏览器是否发送了有效的 If-Modified-Since header 。它的确是。以下是请求 header :

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 以及所有内容。在与页面交互之前等待五分钟到期，主要会产生 200 错误，只有少数 304 错误。这种奇怪的行为适用于 HTML 页面上引用的所有文件(.css、.js、.png 等)以及包含的 HTML 页面本身。我知道我的应用程序编码正确，因为如上所述，直接访问 ELB 而不通过 CloudFront 会产生预期的 304 结果。有什么想法吗？

Answer 1

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

当您配置 CloudFront 将 Cookie 转发到源时 [...] 不支持 If-Modified-Since 和 If-None-Match 条件请求。

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

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

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

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

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

所以就这样了。希望这对某人有帮助。