1
votes

A fairly standard method for specifying cache behaviour in response headers is to set both a Date value and an Expires value. (Along with some kind of cache-control directive such as cache-control=public).

Assuming that a request is made at time now, let's say, now is:

Tue, 24 Jun 2014 13:36:05 GMT

Then a standard response which sets a cache value of 1 hour might include the following headers:

Date: Tue, 24 Jun 2014 13:36:05 GMT
Expires: Tue, 24 Jun 2014 14:36:05 GMT

This would (and should) tell any intermediary caches or PoPs to cache the resource for 1 hour from now.

However, what if both the Expires value and the Date value are in the past. (Perhaps, say, because of an erroneous server clock).

If we consider another request being made at the same time, with now being:

Tue, 24 Jun 2014 13:36:05 GMT

What if the corresponding response contained the following header values:

Date: Tue, 24 Jun 2014 11:10:00 GMT
Expires: Tue, 24 Jun 2014 11:44:00 GMT

Here, both values are already past. An Expires value in the past would normally be enough to trigger a no-cache, but what is the effect of the Date value being in the past.

Should cache implementations use the value of Date to calculate an offset from Expires, and then use that to create an expiry value of now + offset?

RFC2616 Date section
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
Does not mention a Date value in the past

RFC2616 Expires section
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21
Stipulates that if Date === Expires, a reponse is 'already expired'.

Neither of these seem to mention the case where both Date and Expires have already past?

UPDATE / RFC2616 is Dead
Further reading suggests that RFC2616 is dead and has been superseded by a set of more specific RFCs.

The new RFC7234 - HTTP/1.1: Caching contains a Calculating Freshness Lifetime which contains the following statement:

If the Expires response header field is present, use its value minus the value of the Date response header field

This seems to specify exactly what is outlined above - use an expires value of:

expiry=(Expires - Date) + Now

There does not seem to be any equivalent statement in the original RFC. For those still following RFC2616, is the behaviour up to individual browser/cache vendors?

1

1 Answers

1
votes

In 2616, the corresponding section is 13.2.3 Age Calculations.