告诉CloudFront仅缓存200个响应代码 [英] Tell CloudFront to only cache 200 response codes

问题描述

是否可以将Amazon CloudFront配置为仅缓存200个代码？我希望它永远不要缓存3xx，因为我想通过Lambda将其连接到即时图像处理工具，该工具通过S3执行307，如ere https://aws.amazon.com/blogs/compute/使用amazon-s3-aws-lambda和amazon-api-gateway /

Is it possible to configure Amazon CloudFront to only ever cache 200 codes? I want it to never cache 3xx as I want to connect it to an on the fly image processing tool with Lambda that performs a 307 via S3 as described ere https://aws.amazon.com/blogs/compute/resize-images-on-the-fly-with-amazon-s3-aws-lambda-and-amazon-api-gateway/

推荐答案

除非您可以配置源以设置 Cache-Control ，否则没有明确地告诉CloudFront仅缓存2XX而不缓存3XX的方法。标头相应地-CloudFront将2XX和3XX视为成功，并将它们视为相同。 （对于4XX和5XX，它具有不同的规则，并且对条件请求的304响应显然是例外。）

There isn't a way to explicitly tell CloudFront to cache only 2XX's and not cache 3XX's unless you can configure the origin to set the Cache-Control header accordingly -- CloudFront considers 2XX and 3XX as "success" and treats them the same. (It has different rules for 4XX and 5XX only, and an obvious exception for a 304 response to a conditional request.)

对于S3重定向，问题在于这是因为S3重定向规则不允许设置 Cache-Control 标头。

In the case of S3 redirects, the problem with this is that S3 redirection rules do not allow a Cache-Control header to be set.

但是，如果您在S3中创建对象时，正在对象上正确设置 Cache-Control 标头-确实应该如此-然后您可以 probably¹ 通过告诉CloudFront缺少 Cache-Control 标头的响应应完全依靠CloudFront的默认TTL 设置来完全解决问题。不被缓存。这意味着将默认TTL 设置为0，并且当然要求将最小TTL 也设置为0。 ，因为需要最小< =默认值。

However, if you are setting the Cache-Control headers correctly on the objects when you create them in S3 -- as you should be -- then you can probably¹ rely on CloudFront's Default TTL setting to solve the problem entirely, by telling CloudFront that responses lacking a Cache-Control header should not be cached. This would mean setting the Default TTL to 0, and would of course require that the Minimum TTL also be set to 0, since minimum <= default is required.

最大TTL 应该保留其默认值，因为它用于缩短具有最大寿命的对象的CloudFront缓存时间，该时间大于最大TTL 。您不太可能希望缩短2XX响应的可缓存性。

The Maximum TTL should be left at its default value, since it is used to shorten the CloudFront cache time for objects with a max-age that is larger than Maximum TTL. You don't likely want to shorten the cacheability of 2XX responses.

假定浏览器行为正确并且不缓存重定向（对于307或302，重定向不应该这样做） ），则您的问题得到了解决，因为CloudFront在此配置中的行为符合预期-遵守 Cache-Control （如果存在），并且不存在时不缓存响应。

Assuming browsers behave correctly and do not cache the redirect (which they shouldn't, for 307 or 302), then your issue is resolved, because CloudFront behaves as expected in this configuration -- honoring Cache-Control when it's present, and not caching responses when it's absent.

但是，如果您发现浏览器或其他下游缓存正在保留您的重定向，则可能必须变得更具攻击性。

However, you might have to get more aggressive, if you find that browsers or other downstream caches are holding on to your redirects.

在原始不提供响应的情况下，向响应中显式添加 Cache-Control （或其他标头）的唯一方法是使用Lambda @ Edge。以下代码用作原始响应²触发器，会将 Cache-Control：无缓存，无存储，私有（是的，这有点多余）添加到任何 3XX Cache-Control 标头，则它将被覆盖。其他任何响应（例如2XX）都不会被修改。

The only way to explicitly add Cache-Control (or other headers) to responses when the origin doesn't provide them would be with Lambda@Edge. The following code, used as an Origin Response² trigger, would add Cache-Control: no-cache, no-store, private (yes, it's a bit redundant) to any 3XX HTTP response received from an origin server. If any Cache-Control header is present on the origin's response, it would be overwritten. Any other response (e.g. 2XX) would not be modified.

'use strict';

// add Cache-Control: no-cache, ... only if response status code is 3XX

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    if (response.status.match(/^30[27]/))
    {
        response.headers['cache-control'] = [{ 
          key:   'Cache-Control', 
          value: 'no-cache, no-store, private' 
        }];
    }

    callback(null, response);
};

有了此触发器，将不会修改2XX响应的标头，但是302/307响应将如图所示进行修改。这将告诉CloudFront和浏览器不要缓存响应。

With this trigger in place, 2XX responses do not have their headers modified, but 302/307 responses will be modified as shown. This will tell CloudFront and the browser not to cache the response.

¹ 可能 ...并不意味着CloudFront仅可能做正确的事情。 CloudFront的行为完全符合预期。 可能表示这是唯一需要执行的操作：您可以可能认为此解决方案足够了，因为可能浏览器不会缓存重定向。与往常一样，浏览器行为是通配符，可能需要更激进地添加显式 Cache-Control 标头，以防止浏览器对重定向进行缓存。

¹ probably... is not intended to imply that CloudFront merely might do the right thing. CloudFront behaves exactly as expected. Probably refers to this being the only action needed: You can probably consider this solution sufficient, because probably browsers will not cache the redirect. Browser behavior, as usual, is the wildcard that may require the more aggressive addition of explicit Cache-Control headers to prevent caching of the redirect by the browser.

² 原始响应触发器在缓存响应（如果已缓存）并将其返回给查看器之前检查并可以修改响应的某些方面。在流中的这一点上修改或添加 Cache-Control 标头将阻止响应存储在CloudFront缓存中，并且还应防止浏览器缓存。

² Origin Response triggers examine and can modify certain aspects of responses before they are cached (if they are cached) and returned to the viewer. Modifying or adding Cache-Control headers at this point in the flow would prevent the response from being stored in the CloudFront cache, and should prevent browser caching as well.

这篇关于告诉CloudFront仅缓存200个响应代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！