3xx与cloudfront缓存之间有什么关系?

时间:2019-04-24 10:04:26

标签: redirect caching amazon-cloudfront browser-cache

我遇到了这个问题,试图让我对缓存和重定向有所了解。根据我读到的 301 302 http protocol,这就是我的看法,a request sends to server (in this case cloudfront) and triggers a direction(基于配置,但我们认为这是默认设置)。客户端在response中看到 301 302 。如果状态为301,则表示indicates the resources they get backlink has permanently moved返回到客户端。而 302 告诉客户therefore new resources will return

"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

resource is found and here it is, without doing any further action

其他注意事项:

说明在Cloudfront上管理缓存应采取的措施

1 个答案:

答案 0 :(得分:1)

“如果您的来源返回301或307状态代码,则CloudFront不会按照重定向到新位置的方式进行。”

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

它的作用: 客户端-> CloudFront->原始(301)<-> CloudFornt->客户端(获取新位置)

如您所见,CloudFront将响应标头(以及状态代码)转发给客户端,而客户端则需要遵循重定向。

CloudFront不这样做: 客户端-> CloudFront-> Origin(301)-> CloudFront(遵循301并向新位置发出请求)->起源

尽管CloudFront会缓存3xx响应,这意味着下次有人提出相同请求时,CloudFront会从其缓存中提供响应。

当CloudFront服务器301/307自己使用时(不是来自Origin): 通过HTTP到HTTPS重定向(对于GET为301,对于POST为307)或配置为Lambda @ edge进行重定向。