未从Cloudfront返回Content-Encoding标头

时间:2018-02-22 15:37:07

标签: amazon-web-services amazon-s3 amazon-cloudfront

我正在尝试将压缩的CSS和JS文件提供给我的网络应用程序。这些文件托管在S3上,在S3源前面具有Cloudfront分发,以提供边缘缓存。我无法将这些文件都压缩到浏览器并使用正确的缓存相关标头,以便浏览器也可以缓存。

我有一个以UNIX作为Origin的cloudfront发行版,为我的网络应用程序提供JS和CSS文件。我最初设置CloudFront来压缩文件,但它不会在响应中发送ETagCache-Control标头。

由于我也想利用浏览器缓存,我想到了在S3中存储gzip压缩文件,附加了Content-EncodingCache-Control标头。我这样做了,CloudFront确实开始在响应中返回ETagContent-Encoding: gzip标头,但它不会在响应中返回Content-Encoding标头(我在文件元数据中设置了标头)在S3)。由于响应中缺少此标头,因此浏览器不知道要解压缩响应并最终得到一个不可读的文件。

我还尝试设置查看器响应边缘lambda来添加Cache-Control标头,但这是不允许的(请参阅the AWS docs)并导致LambdaValidationError。

这里是否有我遗漏的内容可以让文件通过压缩进入浏览器, AND 仍允许ETagOp标头它通过浏览器?

非常感谢任何帮助!

2 个答案:

答案 0 :(得分:2)

我通常这样做的方法是将未压缩的内容上传到S3存储桶,并在您的项目上放置Cache-Control标头。 Cache-Control标头是我在原点设置的唯一内容(S3)。

在Cloudfront中,我检查“行为设置”中的“自动压缩对象”选项,让Cloudfront为我压缩文件。这会处理Content-EncodingLast-Modified标头以及gzipping。这应该就是你所需要的。您不会在Cloudfront中看到ETag标头,但Last-Modified在这里做的事情基本相同。

如果您没有看到更改,请检查您是否正确使Cloudfront缓存无效。我看到很多人将/放在框中,但实际上/*使整个发布无效。

https://aws.amazon.com/about-aws/whats-new/2015/05/amazon-cloudfront-makes-it-easier-to-invalidate-multiple-objects/

这应该照顾gzipping,从CDN缓存和浏览器缓存。

祝你好运!

答案 1 :(得分:1)

在您的特定情况下,我认为您缺少一点。您需要像这样在Cloudfront中修改分散: ->编辑默认行为[*],然后选择“基于所选请求标头的缓存”,将“接受编码”标头列入白名单。

通常,CloudFront中的缓存方式是:

如果您在CloudFront中启用了压缩,则所有可以压缩的文件都意味着:

将由CloudFront压缩,并且默认情况下将删除etag标头。 CloudFront不会触摸/修改可在s3对象中设置为属性的缓存控制标头。

在诊断带有卷毛的etag消失时可能会造成混淆。默认情况下,Curl将返回etag,因为它不发送标头:

  

“接受编码:gzip,deflate,br”

直到您指定它。对于非压缩内容,Cloud保留etag。

拥有etag可以做的一件事是在cloudfront上禁用压缩,但这意味着成本增加,加载时间增加。

另一件事是在cloudfront上将Accept-Encoding标头列入白名单:->编辑默认行为[*]并选择“基于选定请求标头的缓存”以将“ Accept-Encoding”标头列入白名单并上传压缩的s3对象。请记住相应地设置“内容编码”元数据。在这里,您将找到一条说明:https://medium.com/@graysonhicks/how-to-serve-gzipped-js-and-css-from-aws-s3-211b1e86d1cd

从现在开始,CloudFront将保留缓存的版本并共享etag。更多阅读:https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html?shortFooter=true#header-caching-web-compressed

CloudFront还添加:

  

最后修改时间:2019年7月13日星期六,格林尼治标准时间   标头。

如果存在不带etag的缓存控制,则缓存行为按以下说明工作: https://developer.mozilla.org/pl/docs/Web/HTTP/Headers/Cache-Control

如果最后修改的不是100%,那么浏览器将缓存此类请求的时间不是100%明显。

根据我的经验,当firefox和chrome已缓存该对象时,再次从CloudFront检索该对象时将添加请求标头:

  

如果修改为:自:星期六,2019年7月13日格林尼治标准时间

如果在此日期之后对其进行了修改,则CloudFront将响应将提供适当的数据。

在IE上似乎使用了启发式缓存算法,您可以在此处了解更多信息:https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/

对于IE,该对象可以缓存的时间长度为:(当前时间-最后修改时间)* 10%。