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 Sat, 23 Aug 2014 22:11:35 GMT
On 2014-08-23 17:43, Mark Montague wrote:
>> > - 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).
>> mod_cache shouldn’t remove any Cache-Control headers.
>
> It apparently does, although I haven't found where in the code yet. I 
> would be interested to see if anyone can reproduce my experience. As 
> far as I know, I don't have any configuration that would result in this.

Please ignore this part of my previous reply, I found out what was going on:

When the content is first requested, mod_cache has a miss and it stores 
the content.  But when it sends it on to the client, it does so without 
any Cache-control header at all:

GET /test.php HTTP/1.1
Host: dev.catseye.org

HTTP/1.1 200 OK
Date: Sat, 23 Aug 2014 22:01:26 GMT
Server: Apache/2.4
X-Cache: MISS from dev.catseye.org
X-Cache-Detail: "cache miss: attempting entity save" from dev.catseye.org
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

The second time the resource was requested, it is served by mod_cache 
from the cache with the original Cache-Control header (I added "foo=1" 
to the header track this when I generated the page):

GET /test.php HTTP/1.1
Host: dev.catseye.org

HTTP/1.1 200 OK
Date: Sat, 23 Aug 2014 22:02:21 GMT
Server: Apache/2.4
Cache-Control: max-age=0, foo=1, s-maxage=14400
Content-Security-Policy: default-src 'self'; script-src 'self' 
'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 
'self' data: ; font-src 'self' data: ; report-uri /csp-report.php
Age: 54
X-Cache: HIT from dev.catseye.org
X-Cache-Detail: "cache hit" from dev.catseye.org
Content-Length: 33
Content-Type: text/html;charset=UTF-8

What was happening was that led me to assume that mod_cache was 
"editing" the header (which, I now see, it wasn't) was because I had the 
following directives that escaped my attention when I was composing my 
previous reply:

     ExpiresActive on
     ExpiresDefault "access plus 1 week"
     ExpiresByType text/html "access plus 0 seconds"

This resulted in a "Cache-control: max-age=0" header being 
unconditionally added to the response headers, even if another header 
was already there.  So for a cache miss, I would see:

Cache-control: max-age=0

while for a cache hit I would see

Cache-control: max-age=0
Cache-Control: max-age=0, foo=1, s-maxage=14400

Mystery solved.  I apologize for the red herring and waste of people's 
time and attention.

I'm still looking for a solution to the original problem:  how to 
indicate to mod_cache that cached content for a particular URL path 
should be served to some clients (ones without login cookies), but not 
to other clients (ones with login cookies).

-- 
   Mark Montague
   mark@catseye.org


Mime
View raw message