3xx和cloudfront周围的缓存有什么关系？
What is the relationship between 3xx and caching around cloudfront?
我遇到了这个问题，并试图了解缓存和重定向。根据我阅读的 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.
从上面的引用来看，这是否意味着 301/307 将 return 从后端缓存资源？ Cloudfront 使用重定向的状态代码是否不同？
我知道我有太多问题 post，但我主要关心的是缓存和重定向。有人可以用外行术语解释这种关系吗？提前谢谢你
顺便说一下，这是我触发重定向的方式：
导航到 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>
补充说明：
解释我们应该如何管理 Cloudfront 上的缓存
"If your origin returns a 301 or 307 status code, CloudFront doesn't follow the redirect to the new location."
上一行表示 CloudFront 将响应转发给客户端，而不是遵循 Origin 提供的重定向。
它的作用：
客户端 --> CloudFront --> 来源 (301) <--> CloudFornt --> 客户端（获取新位置）
如您所见，CloudFront 将响应 header（连同状态代码）转发给客户端，客户端需要遵循重定向。
CloudFront 不做：
Client --> CloudFront --> Origin(301) --> CloudFront（跟随 301 并向新位置发出请求）-->origin
虽然 CloudFront 缓存了 3xx 响应，这意味着下次如果有人发出相同的请求，CloudFront 会从它的缓存中提供响应。
当 CloudFront 服务器 301/307 由他自己（不是来自 Origin）时：
HTTP 到 HTTPS 重定向（301 用于 GET，307 用于 POST）或 Lambda@edge 配置为这样做。
我遇到了这个问题，并试图了解缓存和重定向。根据我阅读的 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.
从上面的引用来看，这是否意味着 301/307 将 return 从后端缓存资源？ Cloudfront 使用重定向的状态代码是否不同？
我知道我有太多问题 post，但我主要关心的是缓存和重定向。有人可以用外行术语解释这种关系吗？提前谢谢你
顺便说一下，这是我触发重定向的方式：
导航到 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>
补充说明：
解释我们应该如何管理 Cloudfront 上的缓存
"If your origin returns a 301 or 307 status code, CloudFront doesn't follow the redirect to the new location."
上一行表示 CloudFront 将响应转发给客户端，而不是遵循 Origin 提供的重定向。
它的作用： 客户端 --> CloudFront --> 来源 (301) <--> CloudFornt --> 客户端（获取新位置）
如您所见，CloudFront 将响应 header（连同状态代码）转发给客户端，客户端需要遵循重定向。
CloudFront 不做： Client --> CloudFront --> Origin(301) --> CloudFront（跟随 301 并向新位置发出请求）-->origin
虽然 CloudFront 缓存了 3xx 响应，这意味着下次如果有人发出相同的请求，CloudFront 会从它的缓存中提供响应。
当 CloudFront 服务器 301/307 由他自己（不是来自 Origin）时： HTTP 到 HTTPS 重定向（301 用于 GET，307 用于 POST）或 Lambda@edge 配置为这样做。