On 23 Aug 2014, at 3:40 PM, Mark Montague <m...@catseye.org> wrote:
>> Does this not duplicate the functionality of the If directives?
>
> No, not in this case:
>
> <If "-z %{req:Cookie}">
> CacheEnable disk /
> </If>
>
> [root@sky ~]# httpd -t
> AH00526: Syntax error on line 148 of /etc/httpd/conf/dev.catseye.org.conf:
> CacheEnable cannot occur within <If> section
> [root@sky ~]#
>
> Also, any solution has to work within both the quick handler phase and the
> normal handler phase of mod_cache.
The solution here is to lift the restriction above. Having a generic mechanism
to handle conditional behaviour, and then having a special case to handle the
same behaviour in a different way is wrong way to go.
> The proposed enhancement is about the server deciding when to serve items
> from the cache. Although the client can specify a Cache-Control request
> header in order to bypass the server's cache, there is no good way for a web
> application to signal to a client when it should do this (for example., when
> a login cookie is set). The behavior of other caches is controlled using the
> Cache-Control response header.
There is - use “Cache-Control: private”. This will tell all public caches,
including mod_cache and ISP caches, not to cache content with cookies attached,
while at the same time telling browser caches that they should.
> Here is a more detailed example scenario, in case it helps. There are also
> many other scenarios in which conditionally bypassing mod_cache is useful.
>
> - Reverse proxy setup using mod_proxy_fcgi
> - Static resources served through httpd front-end with response header
> "Cache-Control: max-age=14400" so that they are cached by mod_cache, ISP
> caches, and browser caches.
> - Back-end pages are dynamic (PHP), but very expensive to generate (1-2
> seconds).
> - Back-end sets response header "Cache-Control: max-age=0, s-maxage=14400" so
> that mod_cache caches the response, but ISP caches and browser caches do not.
> (mod_cache removes s-maxage and does not pass it upstream).
mod_cache shouldn’t remove any Cache-Control headers.
> - When back-end content changes (e.g., an author makes an update), the
> back-end invokes "htcacheclean /path/to/resource" to invalidate the cached
> page so that it is regenerated the next time a client requests it.
Set your max-age correctly and this becomes unnecessary. If you have long lived
resources that you want caching for a very long time, and you want to change
that resource, place the version number of the resource in the URL and refer to
the new URL after the change.
> - Clients have multiple cookies set. Tracking cookies and cookies used by
> JavaScript should not cause a mod_cache miss.
> - Dynamic pages that are generated when a login cookie is set should not be
> cached. This is accomplished by the back-end setting the response header
> "Cache-Control: max-age=0”.
This is incorrect, max-age=0 means that a cache is welcome to cache the
content, but the content must be declared stale immediately and revalidated.
> - However, when a login cookie is set, dynamic pages that are currently
> cached should not be served to the client with the login cookie, while they
> should still be served to all other clients.
All of the above is handled by HTTP already, just follow the protocol.
Make sure you separate your cacheable content from your uncacheable content.
Ensure that you use HTTP conditional requests so that expensive calls can be
made cheap. Properly declare the request headers you vary on using the Vary
header, but keep in mind that headers with many variations will DoS a cache.
Cache long-lived content and change the URL if the content is updated. Use
max-age (and s-maxage) on short lived content to make the generation of it
cheap.
Regards,
Graham
—
