Cache future timestamps for a short time

[nickdaugherty]

Instead of sending nocache headers, which has implications for cache servers like Varnish that do hit-for-pass, set a short TTL so the content can be served from cache, but expires when the timestamp becomes valid.

Example of the problem (using Varnish as an example):

• Varnish server that does hit-for-pass caching for 10 seconds
• Client makes a request for 1 second in the future
• Liveblog calls nocache_headers() which sets the max-age to 0 and a 1984 Expires header
• Varnish sees the object is not cacheable
• Varnish marks the object as hit-for-pass
• One second elapses
• Clients continue making requests for the now valid timestamp
• Those requests all go through Varnish to the origin for 10s (until hit-for-pass TTL expires)
• After 10s the request is recached normally

This is obviously very problematic because it means one client requesting a (just barely) invalid timestamp can cause 100% of traffic (for that Varnish server) to bypass Varnish and hit the origin for a period of time.

After this change, the above scenario looks like this:

• Varnish server that does hit-for-pass caching for 10 seconds
• Client makes a request for 1 second in the future
• Liveblog calculates how far into the future the invalid timestamp is
• Liveblog sets the cache headers to expire the object in that many seconds
• Varnish sees the object is cacheable
• Requests keep coming in (both before and after the timestamp becomes valid)
• Varnish serves these requests from cache, skipping origin
• Once timestamp becomes valid, the TTL of the object in Varnish expires
• Varnish sends through a single request to origin to get the object
• Liveblog serves that single request normally (timestamp is now valid)
• Object gets cached in Varnish with normal TTL

[rogertheriault]

Looks great!