On 23 August 2014 14:40:36 GMT+01:00, Mark Montague <m...@catseye.org> wrote: >On 2014-08-23 5:19, Graham Leggett wrote: >> On 23 Aug 2014, at 03:50, Mark Montague <m...@catseye.org >> <mailto:m...@catseye.org>> 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 / ></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. > > >>> # 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 >formal >> 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 >caches >is controlled using the Cache-Control response header. > >This functionality is provided by Varnish Cache: >https://www.varnish-cache.org/docs/4.0/users-guide/increasing-your-hitrate.html#cookies > >Squid does not currently provide this functionality, but it seems like >there is consensus that it should: >http://bugs.squid-cache.org/show_bug.cgi?id=2258 > >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). >- 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. >- 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". >- 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 or Vary: 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 -- Tim Bannister – is...@jellybaby.net
