如果找不到文件，则禁用Cloudfront缓存 [英] Disable Cloudfront cache if file is not found

问题描述

我在S3存储桶前面创建了一个Cloudfront发行版，并使用RoutingRule来重定向到lambda函数（如果找不到请求的文件）。我正在使用它来调整图像大小。

所需的流量：

1. 请求文件到Cloudfront


2. 在Cloudfront中找不到文件检查S3


3. 在S3中找不到文件重定向到lambda函数


4. Lambda将找到原始文件，调整其大小并重定向回Cloudfront网址。

在s3网站上设置的重定向规则：

 < RoutingRules> 
< RoutingRule> 
<条件> 
< KeyPrefixEquals /> 
< HttpErrorCodeReturnedEquals> 404< / HttpErrorCodeReturnedEquals> 
< /条件> 
< Redirect> 
< Protocol> https< / Protocol> 
< HostName> mylambda.execute-api.us-east-1.amazonaws.com< / HostName> 
< ReplaceKeyPrefixWith> /？key =< / ReplaceKeyPrefixWith> 
< HttpRedirectCode> 307< / HttpRedirectCode> 
< / Redirect> 
< / RoutingRule> 
< / RoutingRules> 
  

当lambda函数重定向回原始网址$时，第4步出现问题b $ b Cloudfront缓存了404吗？并且S3的路由规则再次重定向到lambda函数，从而导致循环。

1. 我确认了lambda函数生成了文件。 / li>
   
2. 如果我在Cloudfront上使该文件无效，则可以成功看到它从S3提供）

在404错误页面上添加了0 TTL，但没有帮助。

重定向规则返回307状态代码 [临时重定向] 。但是我不知道该如何设置0 TTL。我在Cloudfront自定义错误响应页面上找不到该选项。

根据

现在，lambda函数将返回

  return {
 statusCode： 200，
 body：图像已转换，
}; 
  

检查Cloudwatch日志我没有看到lambda函数被调用，当我进入

我还添加了一个自定义错误页面，其中404的TTL为0

好消息是，如果我转到api网关，传递key = / photos / resized / test.jpg
，然后转到

解决方案

当然，您可以使用Lambda @ Edge原点响应触发器来修改响应并设置所需的标头。从某种意义上讲，这将是最正确的解决方案，因此也是最可取的解决方案，但仅从理论上讲，因为它会引入不必要的成本和复杂性。

默认TTL是CloudFront内部使用的值，当未找到 Cache-Control 响应标头时...因此，您可以将其设置为0并包括正确的在创建S3对象时，使用 Cache-Control 标头，以便除了重定向之外，不使用默认TTL。我对此不满意的是，没有标题可以坚持要求浏览器也不缓存重定向。

但是您实际上不需要返回重定向到浏览器，在这里。您完全不需要重定向。

借助CloudFront的Origin Failover功能，您可以为发行版设置两个原始-主数据库和辅助数据库，以便在CloudFront检测到您的主要来源不可用时，从次要来源提供您的内容。

https://aws.amazon.com/about-aws/whats-new/2018/11/amazon-cloudfront-announces-support-for-origin-failover/

不可用一词在这里不必要地含糊不清，因为此功能不仅可以做到这一点，而且还能做到你想要什么。要设置触发源故障转移的原因...

您可以选择以下状态代码的任意组合：500、502、503， 504、404或403。

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating

因此，正常的存储桶行为就足够了，不需要重定向规则。

请注意，使用此设置，最终响应是CloudFront可以缓存的唯一内容–无论该响应来自主要（S3）还是次要（通过API网关的Lambda）来源-因此，这消除了缓存瞬态响应的问题。

还请注意，尽管使用了故障转移一词，但CloudFront不会保持原始状态的概念模型，因此即使其他请求失败，每个请求也会独立存在，并且会转到主要起源。

I created a Cloudfront distribution in front of an S3 bucket with a RoutingRule to redirect to a lambda function if the requested file is not found. I´m using this to resize images.

Desired flow:

1. Request the file to Cloudfront
2. File not found in Cloudfront check S3
3. File not found in S3 redirect to the lambda function
4. Lambda will find the original file, resize it and redirect back to the Cloudfront url.

Redirect rule set on s3 website:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals/>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>mylambda.execute-api.us-east-1.amazonaws.com</HostName>
      <ReplaceKeyPrefixWith>/?key=</ReplaceKeyPrefixWith>
      <HttpRedirectCode>307</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
</RoutingRules>

I´m having a problem with the step 4 when the lambda function redirects back to the original url Cloudfront cached the 404? and the routing rule from S3 is redirecting again to the lambda function causing a loop.

1. I confirmed that the lambda function generated the file.
2. if I invalidate the file on Cloudfront I successfully see it served from S3)

I tried adding a 0 TTL to the 404 error page but didn´t help.

the redirect rule returns a 307 status code [Temporary Redirect]. But I don´t know how to set a 0 TTL on this. I couldn´t find the option on the Cloudfront custom error response page.

According to this article. the 307 is cached. need to set a rule for it... somewhere .

This is a follow up question on RoutingRules on AWS S3 Static website hosting

I appreciate your help.

Update: 1. Removed the RoutingRule on S3 2. Added a new origin to the Cloudfront distribution (API gateway)

the lambda function now returns

    return {
        statusCode: "200",
        body: "image converted",
    };

Checking Cloudwatch logs I don´t see the lambda function getting invoked and when I go to https://myCloudfront.cloudfront.net/photos/resized/test.jpg

I only see a plain 404

I also added a custom error page with a 0 TTL for 404

the good news is if I go to the api gateway passing key=/photos/resized/test.jpg and then go to https://my.cloudfront.net/photos/resized/test.jpg it works. it reads the image correctly.

I think the problem is with the failover that´s not triggering the api gateway call.

解决方案

You could, of course, use a Lambda@Edge Origin Response trigger, to modify the response and set the header you want. This would, in a sense, be the "most correct" and therefore "most desirable" solution, but only in a theoretical sense, because it introduces unnecessary cost and complexity.

Default TTL is the value that is used by CloudFront, internally, when no Cache-Control response header is found... so, you could set that to 0 and include correct Cache-Control headers when creating your S3 objects, so that the Default TTL wouldn't be used except for the redirects. What I don't like about this is that there's no header to insist that the browser also not cache the redirect.

But you don't actually need to return a redirect to the browser, here. You don't need a redirect at all.

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

https://aws.amazon.com/about-aws/whats-new/2018/11/amazon-cloudfront-announces-support-for-origin-failover/

The word "unavailable" is unnecessarily vague, here, because this feature does more that that, and it will do what you want. To set what triggers origin "failover"...

You can choose any combination of the following status codes: 500, 502, 503, 504, 404, or 403.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating

So just the normal bucket behavior is sufficient, no redirect rules required.

Note that with this setup, the final response is the only thing that can be cached by CloudFront -- whether that reaponse is from the primary (S3) or secondary (Lambda via API Gateway) origin -- so this elmiminates the issue with transient responses being cached.

Note also that despite the use of the word "failover," CloudFront does not maintain a conceptual model of the state of the origin, so each request stands on its own and will go to the primary origin even when other requests are "failing."

这篇关于如果找不到文件，则禁用Cloudfront缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！