在响应标头中指定缓存行为的一种相当标准的方法是设置Date值和Expires值。 （以及某种缓存控制指令，如cache-control=public）。
假设现在现在发出请求，请说， now 是：
Tue, 24 Jun 2014 13:36:05 GMT
然后，将缓存值设置为1小时的标准响应可能包括以下标题：
Date: Tue, 24 Jun 2014 13:36:05 GMT
Expires: Tue, 24 Jun 2014 14:36:05 GMT
这将（并且应该）告诉任何中间缓存或PoP从现在缓存资源1小时。
但是，如果Expires值和 Date值都是过去的，那该怎么办呢？ （也许，比方说，因为错误的服务器时钟）。
如果我们考虑同时提出另一项请求， now 为：
Tue, 24 Jun 2014 13:36:05 GMT
如果相应的响应包含以下标头值，该怎么办：
Date: Tue, 24 Jun 2014 11:10:00 GMT
Expires: 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，则已经过期＆＃39; 。
这些似乎都没有提及Date和Expires已经过去的情况？
UPDATE / RFC2616已死亡
进一步阅读表明RFC2616 is dead已被一组更具体的RFC取代。
新的RFC7234 - HTTP/1.1: Caching包含Calculating Freshness Lifetime，其中包含以下声明：
如果存在Expires响应标头字段，请使用其减去值 Date响应头字段的值
这似乎准确地说明了上面概述的内容 - 使用过期值：
expiry=(Expires - Date) + Now
原始RFC中似乎没有任何等效声明。对于那些仍然遵循RFC2616的人来说，个人浏览器/缓存供应商的行为是什么？
答案 0 :(得分：1)
在2616年，相应的部分是13。2。3年龄计算。