There are two types of expiration policies: relative and absolute expirations. Relative expirations occur when a set period of time has passed after a response, while absolute expirations occur at a specified time.
If you want to set a relative expiration, use the Cache-Control: max-age
directive, which contains the number of seconds for which the response should be cached. The HTTP protocol allows you to set an absolute expiration using the HTTP Expires: header to an RFC 822 compatible date. However, if you set the header directly and later use the cache object model, the output cache recognizes that you have made modifications. It will set the cache header itself as the response is sent out. Therefore, it is highly recommended that you use the ASP+ object model and @ Output Cache directive to set these values.
Many Web servers add another twist on top of relative expirations: they allow administrators to always expire items relative to their request time. For example, if a site administrator decided that all images were valid for at least 24 hours, they could enable a policy which would cause the server to emit either Expires:
or
indicating that the resource expires 24 hours from the time the response is sent.Cache-Control: maxage
The ASP+ output cache enables these scenarios in the following ways.
Note All forms of expiration end up being set in the same way: as an absolute date with anExpires:
header or with aCache-Control: maxage
directive. The difference is that sliding expiration is renewed whenever the response is sent. Absolute and relative expiration differ only in the APIs used to set them.
See Also
ASP+ Output Cache | Preserving Restrictions | System.Web Namespace | HttpCachePolicy Class | OutputCacheItemInformation Class | HttpCacheability Class