Any takers?
>From another discussion level I wanted to see if cache disk could
compete with Varnish, eg:
- Apache + mod_cache_disk + mod_ssl
could be a better stack than
- Apache + Varnish + Pound.
So far, I'm under the impression that managing a reverse-caching proxy
with mod_cache is, if even realistically possible, by far more complex
and less powerful than Varnish.
That's pretty hard to believe since being an Apache module, mod_cache
theorically benefits from a better integration and higher "knowledge"
from the backend HTTPd.
As an example, caching dynamic resources having different query strings
is a non-issue using Varnish (or most other reverse-proxy caches).
What makes mod_cache so specific in this regard?
On Tue, Nov 10, 2015 at 10:58:28AM -0300, Raphaël wrote:
> Hi,
>
> using php/fcgi, I've a Content Management System whose entry-point is
> /index.php
> On the Apache-side it makes use of FallbackResource
>
> According to the documentation:
> > As a filter, mod_cache can be placed in front of content originating
> > from any handler, including flat files (served from a slow disk cached
> > on a fast disk), the output of a CGI script or dynamic content
> > generator, or content proxied from another server.
>
>
> I want to benefit from this fine grained control and configure it as:
>
> > <VirtualHost *:80>
> > ServerName website
> > DocumentRoot "/var/www/website"
> > <Directory "/var/www/website">
> > Require all granted
> > AllowOverride None
> > <FilesMatch \.php$>
> > SetHandler "proxy:unix:/var/run/php5-fpm-website.sock|fcgi://blah"
> > </FilesMatch>
> > FallbackResource /index.php
> > </Directory>
> >
> > <Proxy fcgi://blah max=5>
> > </Proxy>
> >
> > CacheHeader On
> > CacheDetailHeader On
> > CacheQuickHandler Off
> >
> > <Location "/cacheit">
> > CacheEnable disk
> > </Location>
> >
> > <Location "/dontcache">
> > CacheDisable on
> > </Location>
> > </VirtualHost>
>
>
> A sample, not significant, index.php file inside /var/www/website:
> > <?php
> > $uri = trim($_SERVER['REQUEST_URI'], '/');
> > if ($uri == 'cacheit') header('Cache-Control: max-age=30');
> > elseif ($uri == 'dontcache') header('Cache-Control: no-cache');
>
>
> There are multiple issues, whatever syntax/order variations is used, like
> > `CacheEnable disk /`
> at the VirtualHost level.
>
>
> But the first one being that the <Location> directive are *not* taken into
> account.
> A sample of mod_cache debug output, when a `GET /dontcache` is issued soon
> after `GET /cacheit` (and results in a cached output):
> > cache_storage.c(664): AH00698: cache: Key for entity /index.php?(null) is
> > http://website:80/index.php?
> > mod_cache_disk.c(572): AH00709: Recalled cached URL info header
> > http://website:80/index.php?
> > mod_cache_disk.c(885): AH00720: Recalled headers for URL
> > http://website:80/index.php?
> > mod_cache.c(601): AH00761: Replacing CACHE with CACHE_OUT filter for
> > /index.php
> > mod_cache.c(652): AH00763: cache: running CACHE_OUT filter
> > mod_cache.c(681): AH00764: cache: serving /index.php
>
> Indeed htcacheclean -A only shows one unique version of stored, keyed
> "index.php"
>
>
> I did some attempts using `CacheQuickHandler On` and was able to get
> distinct cache entries for /cacheit and /dontcache.
> That was good but it does not solve the issue of <Location> not being
> taken into account (and the CacheEnable flag not being respected):
>
> Eg:
> > <Location "/private">
> > CacheDisable on
> > </Location>
> is not respected (wild guess: because /private is not a "real" resource)
>
>
> Moreover I'd rather stick with a normal cache handler since I hope it'd would
> make possible to insert Header/RequestHeader and I also expect to
> use things like:
> > SetEnvIfNoCase Cookie admin_cookie no-cache
> that the CacheQuickHandler would not treat.
>
>
> Question:
> Is there any way to make CacheEnable work on a granular <Location> basis
> when a FallbackResource is used and that the <Location> parameter is the
> original un-rewritten URL?
>
>
> Thank you!
--
GPG id: 0xF41572CEBD4218F4
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]