Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Date: Tue, 22 Dec 2015 11:59:23 -0300
From: =?iso-8859-1?Q?Rapha=EBl?= <raphael.droz@gmail.com>
To: users@httpd.apache.org
Message-ID: <20151222145923.GA17004@debovo.drzraf.me>
References: <20151110135828.GB7909@debovo.drzraf.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20151110135828.GB7909@debovo.drzraf.me>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [users@httpd] Re: mod_cache for FallbackResource?

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: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org