如何告诉cloudfront不缓存来自S3重定向的302响应,或者如何解决此图像缓存生成问题

Question

我正在通过LIIPImagineBundle为Symfony2使用Imagine来创建存储在S3中的图像的缓存版本.

缓存的图像存储在CloudFront提供的支持S3 Web的存储桶中.但是,S3的默认LIIPImagineBundle实现对我来说太慢了(检查S3上的文件是否存在然后创建到缓存文件或解析功能的URL),所以我已经计算出了我自己的工作流程:

1. 向客户端传递缓存图像应存在的云端URL
2. 客户端通过云端URL请求映像,如果它不存在则S3存储桶具有重定向规则,302将用户重定向到想象网络服务器路径,该路径生成文件的缓存版本并将其保存到S3上的适当位置
3. webserve 301将用户重定向回现在存储图像的云端URL,并为客户端提供图像.

只要我不使用cloudfront,这工作正常.问题似乎是cloudfront正在缓存302重定向响应(即使http规范声明它们不应该).因此,如果我使用cloudfront,则客户端将在无限重定向循环中从Web服务器到云端来回发送,并且即使在生成文件之后,对文件的每个后续请求仍会重定向到Web服务器.

如果我直接使用S3而不是cloudfront,则没有问题,这个解决方案是可靠的.

根据亚马逊的文档 S3重定向规则不允许我指定自定义标头(设置缓存控制标头等),我不相信CloudFront允许我控制重定向的缓存(如果它们做得很好)隐).CloudFront的失效选项是如此有限,以至于我认为它们不会起作用(任何时候都只能使3个​​对象失效)...我可以在第一次重定向(来自Imagine webserver)上将参数传递回cloudfront来修复无穷无尽的重定向(例如image.jpg？1),但是对同一对象的后续请求仍然是302到网络服务器然后301返回到云端,即使它存在.我觉得应该有一个优雅的解决方案来解决这个问题,但它让我望而却步.任何帮助,将不胜感激!!

Answer 1

我通过在CloudFront"缓存行为"设置中设置"默认TTL"来解决同样的问题0,但仍然允许通过CacheControl在S3文件上设置MetaData 来缓存我调整大小的图像max-age=12313213.

这样重定向将不会被缓存(默认TTL行为),但我调整大小的图像将是(缓存命中的CacheControl max-age).

Answer 2

如果你真的需要在这里使用CloudFront，我唯一能想到的是你不要\xe2\x80\x99t直接让用户接受302、301舞蹈。您能否向前端 S3 介绍某种代理脚本/页面以及整个过程？（或者这是否会破坏要点）。

\n\n

所以缓存未命中看起来像这样：

\n\n

\n
• 访问者通过 Cloudfront 请求代理页面。
\n
• 代理页面从 S3 请求图像
\n
• 代理页面从 S3 接收到 302，按照此到达 Imagine web\n服务器
\n
• 理想情况下，只需从此处返回图像（同时让它更新\nS3），或按照 301 返回 S3
\n
• 代理页面将图像返回给访问者
\n
• 图像由 Cloudfront 缓存
\n

\n