9

The Expires header can be set to a date in the past to prevent caching, although this seems to be regarded as an unusual practice. Any date before today should work for this purpose, but Wordpress uses the very specific date of Wed, 11 Jan 1984 05:00:00 GMT for some reason. I'm pretty sure that WP is the origin of this practice since all discussions involving this date appear to be about WordPress, and this article specifically calls out the Expires header value as a sign of a WordPress server. This blog post remarks upon the unusual date but has nothing very useful to offer about it (unless the cache control headers are meant to honor the death of Fritz Geissler).

It seems to me like it would have been better practice to choose a more generic timestamp like 1 Jan 1900 00:00:00 GMT to avoid surprise at the specificity. It has demonstrably caused some degree of confusion (albeit not much), as can be seen from this forum post. Does anybody know what this date's significance is or why the WordPress developers chose it? I can only assume it's some kind of Easter egg, but it'd be neat to find out the details.

Hydrothermal
  • 4,851
  • 7
  • 26
  • 45

1 Answers1

14

Looks like this goes back to WordPress version 2.1.

Doing a bit of digging, the first use of this date in a functions.php was in commit 2623, where it was used in the nocache_headers() function.

Prior to that, it had been copied & pasted around a few times. I think the first instance of this was commit 1983, where the non-cachable date in one case was changed from the birthdate of "Michel" (maybe Michel Valdrighi?) to the 1984 date. The message on that commit is:

Don't cache. No, really. Hat tip: Kimmo Suominen.

That commit came from Matt Mullenweg, whose birthday is listed as 11 January 1984 by Wikipedia.

s3cur3
  • 2,749
  • 2
  • 27
  • 42
  • Great digging! Thanks for the research. – Hydrothermal Jan 02 '19 at 21:41
  • ...that's some awesome sleuthing! – ashleedawg Oct 30 '19 at 06:14
  • In changeset 1983 you can see the date already used in `wp-comments-post.php`. It was changed there actually 3 days earlier in [Changeset 1964 for trunk/wp-comments-post.php](https://core.trac.wordpress.org/changeset/1964/trunk/wp-comments-post.php) by (surprise, surprise) saxmatt, as well. – Speravir Dec 01 '19 at 19:16
  • Too bad, this anti-caching practice does not work. Chrome and Firefox (and probably Edge) all ignore it and serve Wordpress from cache, even claiming a 200-OK response code instead of 305-not changed. As observed today! In addition, my iframe also gets served from cache, although I just uploaded it afresh (the html). – Peter Jul 27 '21 at 19:48