应用错误收集

在撰写以下答案的几天内，已向Cloudfront宣布更改。 Cloudfront现在将通过您选择的标头，并可以添加自己的标头。

然而，我在下面说的很多内容仍然是正确的。请注意，在公告中，提供了一个选项来转发所有标头，正如我所建议的那样，它将有效地禁用缓存。还有一个转发特定标头的选项，这将导致Cloudfront将对象缓存到完整的转发标头集 - 而不仅仅是uri - 意味着缓存的有效性有所降低，因为Cloudfront没有选择，只能假设包含头可能会修改服务器为该请求生成的响应。

您的每个CloudFront发行版现在都包含要转发到源服务器的标头列表。您有三种选择：

None - 此选项请求原始行为。

All - 此选项转发所有标头并有效禁用边缘的所有缓存。

Whitelist - 此选项可让您完全控制要转发的标头。列表开始为空，并随着添加更多标题而增长。您可以通过从列表中选择它们来添加常见的HTTP标头。您也可以通过输入名称来添加“自定义”标题。

如果选择Whitelist选项，则添加到列表的每个标头都将成为与分发关联的URL的缓存键的一部分。向列表添加标头只会告诉CloudFront标头的值可以影响源服务器返回的内容。

http://aws.amazon.com/blogs/aws/enhanced-cloudfront-customization/

在缓存内容的世界中，Cloudfront会删除Referer标题以及其他几个不特别有意义的标题 - 或其存在会导致不合逻辑的后果。

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html

就像cookie一样，如果允许保留Referer:标题，以便原点可以看到它并对其作出反应，那就意味着该对象应该根据请求加上引用页面进行缓存，这似乎在很大程度上打败了物体的可达性。否则，如果原点确实对不受欢迎的引用者做出反应并发送无缓存响应，那么在第一个合法请求进入之前，这将是好的和好的，其响应将被提供给后续请求者，无论他们的引用者如何，打败目的。

RFC-2616第13节要求缓存返回一个响应，该响应已“检查原始服务器将返回的内容的等效性”，这意味着响应基于 all 有效请求中的标题。

User-agent以及原始服务器可能用来修改其响应的其他标题也是如此...如果你需要对原点的这些值做出反应，那么用CDN提供它们几乎没有明显的目的

引用基于页面的测试是一种非常原始的测量方法，就像许多人使用它们一样，因为标题是非常容易伪造的。

如果您正在处理一个您无法控制的平台，这是您需要覆盖的（使用虚拟值，只是为了保持现有系统“满意”），然后在前面的反向代理源服务器可以用于此目的，Cloudfront使用反向代理作为其来源。

Amazon Cloudfront删除Referer标头

2 个答案: