httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Montague <m...@catseye.org>
Subject Re: [RFC] enhancement: mod_cache bypass
Date Sun, 24 Aug 2014 16:57:32 GMT
On 2014-08-23 12:36, Graham Leggett wrote:
> On 23 Aug 2014, at 3:40 PM, Mark Montague <mark@catseye.org> wrote:
>
>> [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 ~]#
> 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.

I've looked into allowing CacheEnable directives within <If> sections.  
This can be done by removing the NOT_IN_FILES flag from the call to 
ap_check_cmd_context() in modules/cache/mod_cache.c:add_cache_enable()

The problem is that <If> sections are currently walked only during 
mod_cache's normal handler phase, not during the quick handler phase.  
It looks easy enough to add a call to ap_if_walk() to 
cache_quick_handler(), but this would add significant extra processing 
to the quick handler phase, as all <If> expressions for the enclosing 
context would be evaluated, and I think that at the end we'd have to 
discard the results that ap_if_walk() caches in the request record so 
that they can be recomputed later during normal request processing after 
all information about the request is available.   Is this acceptable?

Also, the proof of concept patch that I sent yesterday, which adds an 
expr= clause to the CacheEnable directive, records cache bypasses in the 
request notes (for logging), in the X-Cache and X-Cache-Detail headers, 
in the cache-status subprocess environment variable, and adds a new 
subprocess environment variable named cache-bypass.  If we enable using 
CacheEnable in <If> sections, conditional cache bypasses will no longer 
be called out explicitly to the server administrator; they will need to 
infer a bypass from comparing the URL path to their configuration.  I do 
not see this as a large problem, but I thought I would mention it for 
consideration.

Given these things, what thoughts does the developer community have?  
Would a patch to allow CacheEnable within <If> sections have a better 
chance of being accepted than one that adds a expr= clause to the 
CacheEnable directive?

Or should mod_cache not allow cache bypassing at all?  "Use NGINX ( 
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_bypass 
) if you want that" or "use Varnish ( 
https://www.varnish-cache.org/docs/4.0/users-guide/increasing-your-hitrate.html#cookies 
) if you want that" are answers I'm fine with, if there's no interest in 
this feature for httpd's mod_cache.

-- 
   Mark Montague
   mark@catseye.org


Mime
View raw message