> Why does HTTP specify such odd stuff It doesn't, at least anymore, though I agree it would've been good if they'd specified some reasoning for that magical v

> Why does HTTP specify such odd stuff It doesn't, at least anymore, though I agree it would've been good if they'd specified some reasoning for that magical value. Granted it only changed in June, but he's quoting an obsolete RFC. (And if you look up the RFC on the IETF's website, the header color will indicate this, along with the "Obsoleted by…") Currently that section¹ actually reads: > Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and many caches will evict a response far sooner than that. Honestly, they could have just specified a "never" value, like the word "never". That said, I'm not sure a forever resource would be a good idea: the other side's cache would never empty, and honestly, I don't think I've ever seen a piece of data that never changed, either because the spec did eventually change, or the data was incorrect due to human error, etc. Further, you can't really guarantee a response will be cached forever: caches get cleared all the time for a variety of reasons. Cache to reduce load, not to put some sort of new behavior in the system. ¹http://tools.ietf.org/html/rfc7234#section-5.3 http://tools.ietf.org/html/rfc7234#section-5.3