Question

这是我对Javascript文件的curl -I响应：

    HTTP/1.1 200 OK
    Content-Type: text/javascript
    Content-Length: 72640
    Connection: keep-alive
    Date: Sat, 18 Feb 2017 16:12:06 GMT
    Cache-Control: 86400
    Last-Modified: Wed, 15 Feb 2017 15:09:28 GMT
    ETag: "a6ee06ff5e49a4290bb2aabe5e0f9029"
    Server: AmazonS3
    Vary: Accept-Encoding
    Age: 1173
    X-Cache: Hit from cloudfront
    Via: 1.1 3b17302562f1709d8b6c9f7be1.cloudfront.net (CloudFront)

我可以在那里看到Cache-Control标记。不确定Vary和ETag正在做什么，但也是如此。这是否以某种方式指定用户的浏览器不缓存此文件？为什么Pingdom或Goog PageSpeed没有将其识别为浏览器可缓存的文件？

Answer 1

您的Cache-Control标头存在，但该值实际上无效。正确的格式如下所示：

Cache-Control: max-age=86400

这个数字本身就没有意义。

ETag:是实体标记 - 一个不透明的值，用于唯一标识给定URL的当前内容。如果内容发生变化，ETag也会发生变化。具有缓存副本的浏览器可以使用此值来通过发送If-None-Match:请求标头（包括最后看到的ETag），请求服务器仅在内容不同时返回内容。

Vary:告诉浏览器，对请求的某些更改可能会生成不同的响应。与浏览器不同，除非您指定--compressed选项，否则curl不会宣传其支持gzipped有效负载的能力。在调用curl时添加该选项会触发向请求添加Accept-Encoding: gzip，如果您在CloudFront中启用了该选项，可能会触发要压缩的响应。

Cloudfront - 为什么这不是＆＃34;浏览器缓存＆＃34;？

1 个答案: