Amazon Cloudfront Cache-Control:否-缓存头在24小时后无效
我正在用S3托管一个静态网站，并使用Cloudfront缓存文件。实际上，我有3个文件，它们的标题如下：
公共缓存控制: no-cache)
- app.js (缓存控制:max-index.html=63072000，(缓存控制:max-
- =63072000，index.html)
我的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文件无效。然后在这一天剩下的时间里一切都会正常。第二天，我又遇到了同样的问题。
这里发生了什么事？
回答 2
Stack Overflow用户
发布于 2013-09-13 14:09:11
验证CloudFront分发版的Minimum TTL是否设置为0。如果将其设置为任何其他值，CloudFront将不会考虑no-cache标头，并且仍然会为Minimum TTL缓存该文件。有关缓存指令的更多详细信息，可以在此处找到：
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
如果这不起作用，试着调试index.html的实际HTTP请求，并在这里发布响应头，这样我们就可以看看它们了。
此外，除了对index.html文件使用no-cache之外，您还可以尝试使用
public, must-revalidate, proxy-revalidate, max-age=0
这将允许CloudFront将文件存储在边缘位置，但它将强制它在每次请求时使用源重新验证该文件。如果文件没有更改，CloudFront将不需要从源位置传输文件的全部内容。这可以加快响应时间，特别是对于较大的文件。
Stack Overflow用户
发布于 2020-08-13 00:55:42
这更像是一种评论，但有点太长了。希望能帮助其他在这里登陆的人。
通过查询参数进行缓存破坏是有缺点的，尽管您可能可以通过Cloudfront行为来解决所有这些问题。参见https://stackoverflow.com/a/24166106/630614。尽管如此，我仍然建议使用唯一的文件名，例如app.css?v=14113e2c764变成app.14113e2c764.css。
为了回应BradLaney的评论/问题：如果你已经更新了缓存控制标头，但没有看到更改，这是因为原始项目已经被缓存了-无效它，你应该在下一次查看资源时看到新的标头。
关于在为S3项目设置缓存控制时的竞态条件，或者只是在一般情况下为SPA设置缓存控制，这是我的团队工作得很好的地方：
# Sync all files with 1 week cache-control, excluding .html files.
aws s3 sync --cache-control 'max-age=604800' --exclude *.html dist/ s3://$AWS_BUCKET/
# Sync remaining .html files with no cache.
aws s3 sync --cache-control 'no-cache' dist/ s3://$AWS_BUCKET/https://stackoverflow.com/questions/18774069
复制相似问题