Amazon Cloudfront Cache-Control:24小时后,无缓存标头无效 [英] Amazon Cloudfront Cache-Control: no-cache header has no effect after 24 hours

查看:338
本文介绍了Amazon Cloudfront Cache-Control:24小时后,无缓存标头无效的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在S3中托管一个静态网站,并使用Cloudfront缓存文件。我基本上有3个带有以下标头的文件:




  • index.html(缓存控件:无缓存)

  • app.js(缓存控制:max-age = 63072000,公共)

  • style.css(缓存控制:max-age = 63072000,公共)



我的html文件使用查询字符串参数,该参数在每次更新css或js文件时都会更新。我已将s3配置为传递这些参数,并且已验证它可以使缓存的资源无效。我的index.html文件看起来像这样:

 < html> 
< head>
...
< link rel = stylesheet href = app.css?v = 14113e2c764>
< / head>
< body>
...
< script src = app.js?v = 14113e2c764>< / script>
< / body>
< / html>

当我整天推送更新时,它似乎工作得很好,但是第二天早上,推动我的下一个更改,index.html文件已过期。它没有正确的?v =参数,而是旧的参数!修复它的唯一方法是手动使html文件无效。然后,其余的一切在一天的剩余时间内都可以正常工作。第二天,我又遇到了同样的问题。



这是怎么回事?

解决方案

验证CloudFront发行版的最小TTL 设置为0。如果将其设置为任何其他值,则CloudFront将不遵守 no-cache 标头,并且仍会为最小TTL 缓存文件。可以在这里找到有关缓存指令的更多详细信息:



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



如果这无济于事,请尝试调试 index.html 的实际HTTP请求,然后在此处发布响应标头,以便我们进行了解。



此外,您可以尝试使用 no-cache 作为index.html文件>

公共,必须重新验证,代理重新验证,最大年龄= 0



这将允许CloudFront将文件存储在边缘位置,但是将在每次请求时强制其使用源重新验证文件。如果文件未更改,则CloudFront无需从原始位置传输文件的全部内容。这可以加快响应时间,尤其是对于较大的文件。


I'm hosting a static website in S3 and using Cloudfront to cache files. I've essentially got 3 files with the following headers:

  • index.html (Cache-Control: no-cache)
  • app.js (Cache-Control: max-age=63072000, public)
  • style.css (Cache-Control: max-age=63072000, public)

My html file uses query string parameters that get updated every time I update my css or js files. I've configured s3 to pass these parameters through and I've verified that it works to invalidate cached resources. My index.html file looks something like this:

<html>
    <head>
        ...
        <link rel="stylesheet" href="app.css?v=14113e2c764">
    </head>
    <body>
        ...
        <script src="app.js?v=14113e2c764"></script>
    </body>
</html>

It seems to work great as I push updates all day, but when I come in the next morning and push my next change, The index.html file is out of date. Instead of having the correct ?v= parameter, it has the old one! The only way to fix it is to invalidate the html file manually. Then everything works for the rest of the day. The next day I have the same problem again.

What's going on here?

解决方案

Verify that the CloudFront distribution's Minimum TTL is set to 0. If it's set to any other value, CloudFront won't respect the no-cache header and will still cache the file for the Minimum TTL. More details about the caching directives can be found here:

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

If this doesn't help, try to debug the actual HTTP request for index.html and post the response headers here so we can have a look at them.

Also, instead of using no-cache for the index.html file, you can try using

public, must-revalidate, proxy-revalidate, max-age=0

This will allow CloudFront to store the file on the edge location, but it will force it to revalidate it with the origin with each request. If the file hasn't changed, CloudFront will not need to transfer the file's entire content from the origin. This can speed up the response time, especially for larger files.

这篇关于Amazon Cloudfront Cache-Control:24小时后,无缓存标头无效的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆