What Can be Cached?
As mentioned already, the two styles of caching in Apache work differently, mod_file_cache caching maintains file contents as they were when Apache was started. When a request is made for a file that is cached by this module, it is intercepted and the cached file is served.
mod_cache caching on the other hand is more complex. When serving a request, if it has not been cached previously, the caching module will determine if the content is cacheable. The conditions for determining cachability of a response are;
- Caching must be enabled for this URL. See the
CacheEnableandCacheDisabledirectives. - The response must have a HTTP status code of 200, 203, 300, 301 or 410.
- The request must be a HTTP GET request.
- If the request contains an "Authorization:" header, the response will not be cached.
- If the response contains an "Authorization:" header, it must also contain an "s-maxage", "must-revalidate" or "public" option in the "Cache-Control:" header.
- If the URL included a query string (e.g. from a HTML form GET method) it will not be cached unless the response specifies an explicit expiration by including an "Expires:" header or the max-age or s-maxage directive of the "Cache-Control:" header, as per RFC2616 sections 13.9 and 13.2.1.
- If the response has a status of 200 (OK), the response must also include at least one of the "Etag", "Last-Modified" or the "Expires" headers, or the max-age or s-maxage directive of the "Cache-Control:" header, unless the
CacheIgnoreNoLastModdirective has been used to require otherwise. - If the response includes the "private" option in a "Cache-Control:" header, it will not be stored unless the
CacheStorePrivatehas been used to require otherwise. - Likewise, if the response includes the "no-store" option in a "Cache-Control:" header, it will not be stored unless the
CacheStoreNoStorehas been used. - A response will not be stored if it includes a "Vary:" header containing the match-all "*".
What Should Not be Cached?
In short, any content which is highly time-sensitive, or which varies depending on the particulars of the request that are not covered by HTTP negotiation, should not be cached.
If you have dynamic content which changes depending on the IP address of the requester, or changes every 5 minutes, it should almost certainly not be cached.
If on the other hand, the content served differs depending on the values of various HTTP headers, it might be possible to cache it intelligently through the use of a "Vary" header.
Variable/Negotiated Content
If a response with a "Vary" header is received by mod_cache when requesting content by the backend it will attempt to handle it intelligently. If possible, mod_cache will detect the headers attributed in the "Vary" response in future requests and serve the correct cached response.
If for example, a response is received with a vary header such as;
Vary: negotiate,accept-language,accept-charset
mod_cache will only serve the cached content to requesters with accept-language and accept-charset headers matching those of the original request.