When you plan to implement explicit content expiration in your dynamic web pages, keep in mind that the browsers will not reload the pages until they expire. This fact has a number of important consequences:
- If the same URL accessed by different users produces different results, disable caching. Methods described in this article are most suitable for publicly accessible content.
- Set very short expiration periods (or pre-expire with max-age set to zero) on any sensitive or confidential content.
- Changes made to a document will not be seen by the clients until their cached copies expire. You might want to expire newer documents more often than older ones (as they might need more corrections).
- Changes to web design will not be reflected in cached pages until they expire. If you want the expiration period to be more than a few hours, adjust the expiration time based on planned redesign dates.
You can find an ASP library that implements those last two suggestions here. (ASP.NET or PHP implementations would be very similar.) The library contains the following routines:
- getFileModifiedDate returns the modification date of the specified file.
- getCurrentScript returns the physical path to the current web page (to be used with getFileModifiedDate).
- getMinimumValue, when passed an array of values, returns the minimum value.
The library routines are then used in the setExpirationDate routine to calculate the desired expiration date with the following algorithm:
- Content less than a week old should expire in an hour.
- Content less than two weeks old should expire in a day.
- Older content should expire in a week.
- Content should expire no later than the redesign date (if it’s set).
- If the redesign date is in the past, we’ve obviously missed the deadline, so the content should expire in an hour so that the clients will get the new design shortly after it’s finished.