httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Jacobfeuerborn <>
Subject Re: [users@httpd] FilterProtocol cache=no not working correctly in 2.3.15?
Date Mon, 05 Dec 2011 12:11:10 GMT
On 12/05/2011 04:06 AM, Nick Kew wrote:
> On 5 Dec 2011, at 02:27, Dennis Jacobfeuerborn wrote:
>> FilterProvider testfilter TESTFILTER "%{CONTENT_TYPE} = 'text/html'"
>> FilterProtocol testfilter change=yes,cache=no
>> FilterChain testfilter
> FilterProtocol is slightly half-baked: filter modules should tell mod_filter
> their protocol details when they register the filter instead.
> But still, the above *should* cause it to set Cache-Control: no-cache
> on requests where the filter is invoked (are you sure it is?)

These are the response headers I get with the request:
Connection	Keep-Alive
Date	Mon, 05 Dec 2011 11:51:13 GMT
Etag	"35d2-2d-432a5e4a73a80"
Keep-Alive	timeout=5, max=97
Server	Apache/2.3.14 (Unix) mod_ssl/2.3.14 OpenSSL/1.0.0-fips DAV/2

On the request itself I see these cache relavant headers:
Cache-Control	max-age=0
If-Modified-Since	Mon, 11 Jun 2007 18:53:14 GMT
If-None-Match	"35d2-2d-432a5e4a73a80"

>> The filter itself works fine but the problem is that despite specifying cache=no
which according to the documentation should render the output uncacheable when I reload the
page I only get a 304 Not Modfied response.
> If your browser sends a conditional request then the server might send a 304
> without reference to any filters.  The cache=no option just sets the header
> when the filter is invoked.

The filter inserts a header and a footer in the page from two files. I can 
modify these files and don't see an update when I reload but I *do* see an 
update when I shift+reload. So the filter definitely gets invoked.

I get the desired behavior when I add the following to the server config:

Header Set Cache-Control "max-age=0, no-store"

The "no-store" is key here and without it I see the 304's again.

>> I do not see any headers in the response that actually tell the browser that the
content is uncacheable.
>> Any ideas what might be going on here?
> Is anything going on that might cause an internal redirect?
> For example, mod_alias, mod_rewrite, mod_negotiation, any error,
> or anything concerning trailing slashes or directory indexes?
> Or a subrequest, as in SSI?

Not that I know of. This is a new virtual machine that just has the naked 
default apache 2.3.14 installed (not 2.3.15 yet as indicated in the 
subject, I will update that later today).
The DocumentRoot is /var/www/htdocs which contains an index.html with the 
content "<html><body><h1>It works!</h1></body></html>"
which apparently 
comes with the apache source.

The directory index is the only thing that might be involved here but I 
also tested this by explicitly calling /index.html with the same result.

So right now the whole setup is pretty much as minimal as it gets without 
any aliases, rewrites, etc. involved.


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message