为什么 WordPress 使用 1984 年 1 月 11 日作为 Expires 标头的反缓存值？答案

【问题标题】：Why does WordPress use 11 Jan 1984 as an anti-caching value for Expires headers?为什么 WordPress 使用 1984 年 1 月 11 日作为 Expires 标头的反缓存值？
【发布时间】：2019-01-02 20:29:02
【问题描述】：

Expires 标头can be set to a date in the past to prevent caching，尽管这似乎被视为一种不寻常的做法。今天之前的任何日期都可以用于此目的，但 Wordpress uses the very specific date of Wed, 11 Jan 1984 05:00:00 GMT for some reason。我很确定 WP 是这种做法的起源，因为涉及此日期的所有讨论似乎都是关于 WordPress，并且this article 专门将 Expires 标头值称为 WordPress 服务器的标志。 This blog post 对不寻常的日期发表了评论，但没有提供任何有用的信息（除非缓存控制标头旨在纪念 Fritz Geissler 的去世）。

在我看来，最好选择更通用的时间戳，例如 1 Jan 1900 00:00:00 GMT，以避免对特定性感到惊讶。正如from this forum post 所见，它明显引起了一定程度的混乱（尽管不多）。有人知道这个日期的意义或 WordPress 开发人员选择它的原因吗？我只能假设它是某种复活节彩蛋，但最好能找到细节。

【问题讨论】：

可能是生日，还是某个原始编码员的特殊日期？所以，“复活节彩蛋”。

标签： wordpress

【解决方案1】：

看起来这可以追溯到WordPress version 2.1。

稍微挖掘一下，functions.php 中这个日期的第一次使用是 in commit 2623，它在 nocache_headers() 函数中使用。

在此之前，它已经被复制和粘贴了几次。我认为第一个例子是commit 1983，其中一个案例中的不可缓存日期从“Michel”（也许是 Michel Valdrighi？）的生日更改为 1984 年的日期。该提交的消息是：

不要缓存。不完全是。帽子提示：Kimmo Suominen。

该提交来自 Matt Mullenweg，他的生日被列为 1984 年 1 月 11 日by Wikipedia。

【讨论】：

伟大的挖掘！感谢您的研究。
...这是一些很棒的侦探！
在变更集 1983 中，您可以看到 wp-comments-post.php 中已使用的日期。它实际上是在 3 天前在Changeset 1964 for trunk/wp-comments-post.php 中由（惊喜，惊喜）saxmatt 更改的。
太糟糕了，这种反缓存做法不起作用。 Chrome 和 Firefox（可能还有 Edge）都忽略它并从缓存中提供 Wordpress，甚至声称是 200-OK 响应代码而不是 305-未更改。正如今天所观察到的！此外，我的 iframe 也从缓存中获取，虽然我只是重新上传了它（html）。