【发布时间】：2014-08-14 20:14:58
【问题描述】：
在响应标头中指定缓存行为的一种相当标准的方法是同时设置Date 值和Expires 值。 （以及某种缓存控制指令，例如cache-control=public）。
假设在时间现在发出请求，假设现在是：
Tue, 24 Jun 2014 13:36:05 GMT
然后，将缓存值设置为 1 小时的标准响应可能包含以下标头：
Date: Tue, 24 Jun 2014 13:36:05 GMTExpires: Tue, 24 Jun 2014 14:36:05 GMT
这将（并且应该）告诉任何中间缓存或 PoP 从现在开始缓存资源 1 小时。
但是，如果Expires 值和 Date 值都在过去，该怎么办。 （比如说，可能是因为服务器时钟错误）。
如果我们考虑同时提出另一个请求，现在是：
Tue, 24 Jun 2014 13:36:05 GMT
如果相应的响应包含以下标头值怎么办：
Date: Tue, 24 Jun 2014 11:10:00 GMTExpires: Tue, 24 Jun 2014 11:44:00 GMT
在这里，两个值都已经过去了。过去的Expires 值通常足以触发no-cache，但是过去的Date 值会产生什么影响。
缓存实现是否应该使用Date 的值来计算与Expires 的偏移量，然后使用它来创建now + offset 的到期值？
RFC2616 日期部分
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
没有提及过去的日期值
RFC2616 过期部分
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
规定如果Date === Expires，则响应为'已经过期'。
这些似乎都没有提到Date和Expires都已经过去的情况？
更新/RFC2616 已失效
进一步阅读表明RFC2616 is dead 已被一组更具体的 RFC 所取代。
新的RFC7234 - HTTP/1.1: Caching 包含一个Calculating Freshness Lifetime，其中包含以下语句：
如果存在 Expires 响应头字段，则使用其值减去 Date 响应头域的值
这似乎准确地指定了上面概述的内容 - 使用 expires 值：
expiry=(Expires - Date) + Now
原始 RFC 中似乎没有任何等效声明。对于那些仍然遵循 RFC2616 的人，行为是否取决于各个浏览器/缓存供应商？
【问题讨论】：
标签： http caching http-headers cache-control rfc2616