3xx 和云端缓存之间有什么关系？答案

【问题标题】：What is the relationship between 3xx and caching around cloudfront?3xx 和云端缓存之间有什么关系？
【发布时间】：2019-09-13 14:19:27
【问题描述】：

我遇到了这个问题，并试图解决缓存和重定向问题。根据我阅读的 301 和 302 http protocol，这就是我的看法，a request sends to server (in this case cloudfront) and triggers a direction（基于配置，但我们假设这是默认设置）。在response 中，客户端会看到一个301 或302，即indicates the resources they get back。如果状态为301，则表示将link has permanently moved、therefore new resources will return返回给客户端。而 302 告诉客户端 resource is found and here it is, without doing any further action.

"If your origin returns a 301 or 307 status code, CloudFront doesn't follow the redirect to the new location."

从上面的引用中，这是否意味着 301/307 将从后端返回缓存的资源？ Cloudfront 是否使用不同的重定向状态码？

我知道我在一篇文章中有太多问题，但我主要关心的是缓存和重定向。有人可以用外行术语解释这种关系吗？提前谢谢你

顺便说一句，这就是我触发重定向的方式：

导航到https://example.com/index.html

<!DOCTYPE html>
<head>
  <meta http-equiv="refresh" content="0; url=https://example.com/copy/index.html">
  <link rel="canonical" href="https://example.com/copy/index.html">
</head>

补充说明：

Cache control

解释我们应该如何管理 Cloudfront 上的缓存

【问题讨论】：

标签： redirect caching amazon-cloudfront browser-cache

【解决方案1】：

“如果您的源返回 301 或 307 状态代码，CloudFront 不会跟随重定向到新位置。”

以上行表示 CloudFront 将响应转发给客户端，而不是遵循 Origin 提供的重定向。

它的作用：客户端 --> CloudFront --> Origin (301) CloudFornt --> 客户端（获取新位置）

如您所见，CloudFront 将响应标头（连同状态代码）转发给客户端，而需要遵循重定向的是客户端。

CloudFront 不会：客户端 --> CloudFront --> Origin(301) --> CloudFront（跟随 301 并向新位置发出请求）-->origin

虽然 CloudFront 会缓存 3xx 响应，这意味着下次如果有人发出相同的请求，CloudFront 会从其缓存中提供响应。

当 CloudFront 服务器 301/307 由他自己（不是来自 Origin）时： HTTP 到 HTTPS 重定向（GET 为 301，POST 为 307）或配置为执行此操作的 Lambda@edge。

【讨论】：

状态码是 301 还是 302 对从 CloudFront 返回的缓存数据有什么不同吗？如果我对网站进行了更新，并希望在提供新数据时验证和重新缓存数据。
301 和 302 不响应不包含任何数据，因此 CloudFront 仅缓存响应标头，如果您更改内容，CloudFront 从缓存中提供 301/302 ，它没关系，因为客户端将连接的新位置，您需要处理新位置，CloudFront 缓存因此如果数据已更改，您需要执行验证，否则您可以选择 TTL/Cache-Control 配置'不允许 CloudFront 在特定页面上缓存。
谢谢詹姆斯，我想我现在明白你的意思了。感谢您的帮助。刚刚检查了 Cloudfront 缓存控件，我意识到我把注意力放在了错误的问题上，所以它从那里滚雪球。