标头最大值过期
我的 S3 存储桶上有数百万个图像文件，我知道它们永远不会改变。 为了优化请求，我决定在我的文件中添加一个过期标头（如下所述：google page速度规则）
向我的所有文件添加标头的过程既漫长又昂贵，因此我不想重复它。但是，Http Rfc 建议将 Expires 标头设置为未来一年的最大到期日期：
...这意味着我必须在一年内更新我的标题。
我的问题是：
我可以将标头值设置为很远的日期（例如：01-01-2020）并违背 RFC 建议吗？这样做有什么风险？
是否有另一种解决方案可以告诉请求我的文件的客户端将它们无限期缓存，而无需更新我的亚马逊 S3 存储上的任何内容？
I have several millions of image files on a S3 storage bucket and I know they will never change.
To optimize requests, I decided to add an expires header to my files (as explained here : google page speed rules)
The process of adding the headers to all my files is long and expensive so I'd prefer not to repeat it. However, the Http Rfc recommends to set Expires header with a max expiration date of one year in the future :
HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future
...which means I would have to update my headers in one year.
My question is :
Can I set my headers values to a very far date (e.g: 01-01-2020) and go against the RFC recommendation ? What is the risk of doing so ?
Is there another solution to tell the clients that request my files to cache them for an infinite duration, without having to update anything on my amazon S3 storage ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您还可以设置更现代的标头：
每个用户代理在加载每个图像时都愿意将其缓存一整年，然后再请求新的副本。 （其中的大整数是 365 × 24 × 60 × 60 秒。）如果仍然有浏览器不理解 Cache-Control，它们可能会在图像的生命周期中逐渐消失！
You could also set the more modern header:
Each user agent will, upon loading each image, be willing to keep it cached for an entire year before asking for a new copy. (The large integer there is 365 × 24 × 60 × 60 seconds.) If there are still browsers out there that do not understand Cache-Control, they might gradually disappear over the lifespan of your images!
您可以将标头值设置为 2038 年 1 月 19 日左右的最大值（最大 32 位时间戳）。
这就是谷歌一段时间以来在跟踪 cookie 过期时间方面所做的事情。
这样做的唯一风险是，如果有一天，出于某种原因，您决定更改图像（或注意到一个或多个图像存在问题），您的客户将不会下载新版本。您决定是否值得冒这个风险。
除此之外，我真的没有看到任何潜在的问题。
You can set your header values to a maximum of around 19 january 2038 (max 32bit timestamp).
This is what Google did, for some time, on their tracking cookies expiry time.
The only risk of doing so is that if one day, for some reason, you decide to change an image (or notice there is a problem with one or more), your clients will not download the new version. You decide if it's worth taking the risk.
Other than that, I don't really see any potential problem.