Question

我启用了Amazon CloudFront gzip功能：“Compress Objects Automatically”。

我的CloudFront中的所有文件都会发生这种情况，而其他CSS / JS文件正在加载为gzip（Double检查我的服务器请求标头是否接受gzip文件Accept-Encoding: gzip）。

我真的很想弄清楚，因为所有的教程和谷歌搜索结果导致了如何检查单选按钮“自动压缩对象”的相同解释 - 这显然没有帮助。

我想也许我不能gzip文件，因为它们太小而无法压缩 - 但是google speed test明确地说我可以用gzip压缩这些文件。

Compressing https://Cloudfront.cloudfront.net/live/static/rcss/bootstrap.min.css could save 100.3KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/style.css could save 60.5KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/shop/css/jquery.range.css could save 4.6KiB (83% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/font-awesome.min.css could save 21.9KiB (77% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/responsive.css could save 20KiB (80% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/general.min.js?ver=9.70 could save 232.9KiB (72% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/rcss/magnific-popup.css could save 5.7KiB (75% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/bootstrap.min.js could save 26.4KiB (73% reduction).
Compressing https://Cloudfront.cloudfront.net/…ve/static/plugins/jquery.validate.min.js could save 14KiB (67% reduction).
Compressing https://Cloudfront.cloudfront.net/…tic/plugins/jquery.magnific-popup.min.js could save 13.2KiB (63% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/plugins/jquery.range.min.js could save 3.9KiB (66% reduction).
Compressing https://Cloudfront.cloudfront.net/live/static/voting/jquery.cookie.js could save 1.2KiB (53% reduction).

我错过了哪些部分可以帮助我使用Cloudfront gzip文件？

这是我的回复标题的样子：

Accept-Ranges:bytes
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:122540
Content-Type:text/css
Date:Sun, 23 Apr 2017 13:14:07 GMT
ETag:"2cb56af0a65d6ac432b906d085183457"
Last-Modified:Tue, 02 Aug 2016 08:49:54 GMT
Server:AmazonS3
Via:1.1 2cb56af0a65d6ac432b906d085183457.cloudfront.net (CloudFront)
X-Amz-Cf-Id:eCPcSDedADnqDZMlMbFjj08asdBSn7_lfR0imlXAT181Y8qRMtSZASDF27AiSTK8PDQ==
x-amz-meta-s3cmd-attrs:uid:123/gname:ubuntu/uname:ubuntu/gid:666/mode:666/mtime:666/atime:666/md5:2cb56af0a65d6ac432b906d085183457/ctime:666
X-Cache:RefreshHit from cloudfront

编辑：

我理解200和304上的返回概念 - 当删除浏览器缓存时，它总是显示200响应。

所以Cloudfront有一些缓存？我将我的bootstrap3.min.css文件添加到“Invalidation”表中 - 没有用。

确保将文件设置为压缩。

将此添加到我的website.com.conf文件中以启用gzip并显示content-length标题：

DeflateBufferSize 8096
SetOutputFilter DEFLATE
DeflateCompressionLevel 9

尝试从我的DeflateBufferSize 8096文件中删除.conf并将<AllowedHeader>Content-Length</AllowedHeader>添加到“CORS配置” - 我确实获得Content-Length权限 - 但仍然没有GZIPed。（关注CloudFront with S3 website as origin is not serving gzipped files）

这是我目前得到的：

Request URL:https://abc.cloudfront.net/live/static/rcss/bootstrap3.min.css
Request Method:GET
Status Code:200 OK
Remote Address:77.77.77.77:443
Referrer Policy:no-referrer-when-downgrade

Response Headers
Accept-Ranges:bytes
Age:1479
Connection:keep-alive
Content-Length:122555
Content-Type:text/css
Date:Wed, 26 Apr 2017 08:48:34 GMT
ETag:"83527e410cd3fff5bd1e4aab253910b2"
Last-Modified:Wed, 26 Apr 2017 08:43:05 GMT
Server:AmazonS3
Via:1.1 5fc044210ebc4ac6efddab8b0bf5a686.cloudfront.net (CloudFront)
X-Amz-Cf-Id:3ZBgDY0c1WV_Pc0o_Bjwa5cQ9D9T-Cr30QDxd_GvD30iQ8W1ImReQIH==
X-Cache:Hit from cloudfront

Request Headers
Accept:text/css,*/*;q=0.1
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:abc.cloudfront.net
Pragma:no-cache
Referer:https://example.com/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

编辑＃2：

以下：http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

如果将CloudFront配置为压缩内容，CloudFront将从其压缩的文件中删除ETag响应标头。当存在ETag标头时，CloudFront和您的源可以使用它来确定CloudFront边缘缓存中的文件版本是否与源服务器上的版本相同。但是，压缩后两个版本不再相同。

我得到了相同的Etag含义 - 服务的css文件没有经过任何压缩。想想也许我没有为这个特定文件设置压缩权限 - 现在设置为 */bootstrap3.min.css（因为它在目录中）。我之前有这套 bootstrap3.min.css 两者都不起作用。

我的网址是：https://abc.cloudfront.net/live/static/rcss/bootstrap3.min.css 在此之后，我将失效部分编辑为：

/live/static/rcss/bootstrap3.min.css
/static/rcss/bootstrap3.min.css
/rcss/bootstrap3.min.css
/bootstrap3.min.css

这可能是我的实际问题吗？

Answer 1

X-Cache: RefreshHit from cloudfront

这意味着CloudFront使用条件请求（例如If-Modified-Since）检查了原点，响应为304 Not Modified，表明源服务器（S3）上的内容与CloudFront最初缓存资源时的内容保持不变，所以它从缓存中提供了副本。

...在您启用“自动压缩对象”之前可能已缓存。

如果你考虑一下，CloudFront只会压缩来自原点的对象，而不是当它们传递给查看者时效率会高得多，因此它已经拥有的文件永远不会被压缩。

记录在案：

CloudFront在从您的来源获取文件时压缩每个边缘位置中的文件。配置CloudFront以压缩内容时，它不会压缩已位于边缘位置的文件。此外，当文件在边缘位置到期且CloudFront将该文件的另一个请求转发到您的源时，如果您的源返回HTTP状态代码304，CloudFront不会压缩该文件，这意味着边缘位置已经有了该文件的最新版本。如果您希望CloudFront压缩已位于边缘位置的文件，则需要使这些文件无效。

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

因此，*的缓存失效是有序的，以清除未压缩的版本。

但是等等......在同一页面上，似乎有相互矛盾的信息：

注意

如果CloudFront在缓存中有未压缩的文件版本，它仍会将请求转发给原始文件。

鉴于上述信息，这似乎是一个差异。但是，我认为这里的问题是一些未说出口的假设之一。此信息很可能仅适用于为响应未发送Accept-Encoding: gzip的查看器而缓存的未压缩副本，在这种情况下，CloudFront的正确行为是缓存压缩和未压缩的响应如果没有可用的对象的压缩副本并且查看者已经指示它可以支持使用gzip压缩的对象，则无论是否由于来自浏览器的请求而存储了未压缩的副本，都可以独立地联系原点不要宣传gzip支持。

或者，它可以被解释为CloudFront仍然发送请求，但由于响应是304，因此它尽管未被压缩，仍然提供缓存副本。

Invalidate your cache，然后等待失效以显示它已完成，然后再试一次。这应该是纠正这种行为所需的全部内容。

Answer 2

可能是因为S3没有发送所需的Content-Length标头响应。

查看此答案以获取更多详细信息：https://stackoverflow.com/a/42448222/4005566

CSS / JS文件没有启用GZIPed [Amazon CloudFront] - “自动压缩对象”

2 个答案: