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.
--
Mark Montague
m...@catseye.org
