httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <>
Subject Re: [RFC] enhancement: mod_cache bypass
Date Sat, 23 Aug 2014 14:05:58 GMT
On 23 August 2014 14:40:36 GMT+01:00, Mark Montague <> wrote:
>On 2014-08-23 5:19, Graham Leggett wrote:
>> On 23 Aug 2014, at 03:50, Mark Montague < 
>> <>> wrote:
>>> I've attached a proof-of-concept patch against httpd 2.4.10 that 
>>> allows mod_cache to be bypassed under conditions specified in the 
>>> conf files.
>> Does this not duplicate the functionality of the If directives?
>No, not in this case:
><If "-z %{req:Cookie}">
>         CacheEnable disk /
>[root@sky ~]# httpd -t
>AH00526: Syntax error on line 148 of
>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.
>>> # Only serve cached data if no (login or other) cookies are present 
>>> in the request:
>>> CacheEnable disk / "expr=-z %{req:Cookie}"
>> As an aside, trying to single out and control just one cache using 
>> directives like this is ineffective, as other caches like ISP caches 
>> and browser caches will not be included in the configuration.
>> Rather control the cache using the Cache-Control headers in the
>> HTTP specs.
>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
>is controlled using the Cache-Control response header.
>This functionality is provided by Varnish Cache: 
>Squid does not currently provide this functionality, but it seems like 
>there is consensus that it 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
>- 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,
>caches, and browser caches.
>- Back-end pages are dynamic (PHP), but very expensive to generate (1-2
>- 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).
>- 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
>- 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
>be cached.  This is accomplished by the back-end setting the response 
>header "Cache-Control: max-age=0".
>- 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.

A web application can and should use
Cache-Control: private
headers on its responses, to avoid having them be incorrectly served from a shared cache.

I can see a case for webapps having better control over invalidation but I wouldn't do it
like this.

If there's still demand, why not arrange for CacheEnable to be valid within <If>?

Tim Bannister –

View raw message