问HTTP Date报头背后的原理是什么？

EN

根据the spec，它用于年龄计算。如果您不知道服务器认为现在是什么时间，您将无法计算资源的“年龄”。以下是规范中的相关文本：

年龄计算算法摘要，当缓存收到响应时：

age_value

缓存通过此响应接收的Age:标头的值。

date_value

源站Date:头部的值

request_time

是缓存发出导致此缓存响应的请求的(本地)时间

response_time

是缓存接收响应的(本地)时间

now

是当前(本地)时间

apparent_age = max(0，response_time - date_value)；corrected_received_age = max(apparent_age，age_value)；response_delay = response_time - request_time；corrected_initial_age = corrected_received_age + response_delay；resident_time = now - response_time；current_age = corrected_initial_age + resident_time;

只有为了更好地处理Expires报头，才需要Date：

Date: Mon, 26 Mar 2012 12:53:02 GMT
Expires: Wed, 25 Apr 2012 12:53:02 GMT

服务器或客户端的时间可能不正确，因此客户端(浏览器)会尝试calculate max age of the resource freshness。这就是引入Cache-Control标签的原因之一。它使用秒数来过期，而不是固定时间。

我测试了Chrome和Firefox，它们都是没有Date头的响应，所以可以安全地省略它，除非你仍然使用过时的Expires头。如果Date丢失，只需使用assumed the same as client's time。在spec中，头是强制性的，这简直是疯了:日期格式化/解析消耗CPU和网络。

请考虑不使用Date标头，因为它在“禁止标头名称”的列表中。

中的以下描述可能会有所帮助：

禁止的标头名称是不能以编程方式修改的任何HTTP标头的名称；具体地说，是HTTP请求标头名称(与禁止的响应标头名称形成对比)。

禁止修改此类标头，因为用户代理保留对它们的完全控制。以Sec-开头的名称是为创建新的标题而保留的，这些标题不受使用Fetch的API的影响，这些API允许开发人员控制标题，如XMLHttpRequest。

禁止的标头名称以Proxy-或Sec-开头，或者是以下名称之一：

• Accept-Charset
• List item
• Accept-Encoding
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Connection
• Content-Length
• Cookie
• Cookie2
• Date
• DNT
• Expect
• Host
• Keep-Alive
• Origin
• Proxy-
• Sec-
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• Via