httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Woodworth" <>
Subject Re: [users@httpd] Getting mod_perl to run after mod_cache with Apache 2.2.6
Date Thu, 29 Nov 2007 22:53:30 GMT
After some more digging, I've figured out (mostly) what is going on.
It turns out that our mod_perl filter actually does get the body
content from mod_cache -- originally I thought that our filter wasn't
seeing the body at all.  But, the Content-Type header is missing.

In cache_storage.c, around line 120 (in the 2.2.6 source code) there
is this code:

apr_table_unset(h->resp_hdrs, "Content-Type");
 * Also unset possible Content-Type headers in r->headers_out and
 * r->err_headers_out as they may be different to what we have received
 * from the cache.
 * Actually they are not needed as r->content_type set by
 * ap_set_content_type above will be used in the store_headers functions
 * of the storage providers as a fallback and the HTTP_HEADER filter
 * does overwrite the Content-Type header with r->content_type anyway.
apr_table_unset(r->headers_out, "Content-Type");
apr_table_unset(r->err_headers_out, "Content-Type");

While I'm not clear why this is happening, mod_cache is clearing out
the Content-Type header from the response.  So, our mod_perl filter
doesn't see the content-type filter and I think that content-type gets
set again by Apache somewhere after all the filters run.  Since
Content-Type is missing during mod_perl's running, and our mod_perl
filter triggers off of Content-Type being matching certain types
(normally, text/html), our filter doesn't do anything to the body
because the Content-Type is missing.

I was able to "fix" this by commenting out the
apr_table_unset(h->resp_hdrs, ... line above.

Does anyone know the affect that this could have on the rest of
mod_cache/etc (any ill effects, cases where this would break
something, etc?), and why exactly the Content-Type is removed in the
first place my mod_cache?  I see that the comments above try to
explain it, but it doesn't quite make sense to me.


On Nov 29, 2007 2:27 PM, Adam Woodworth <> wrote:
> Hi Nick,
> Thanks for the response!
> > > 1 - mod_cache [ valid content in cache? If so, go to 4; if not,
> > > go to 2] 2 - mod_proxy [fetch content from origin web]
> > > 3 - mod_cache [content cacheable? If so, cache it locally]
> > > 4 - *MY FILTER*
> > > 5 - deflate
> >
> > That makes sense if and only if you want to repeat your-filter and
> > DEFLATE on every request rather than cache the ready-processed contents.
> Yup, due to the nature of our product, our mod_perl filter doesn't do
> the same thing for each request to the same page.
> > directive.  The problem with that is that mod_cache does its own thing.
> Could you ellaborate on what you mean by mod_cache doing its own thing?
> The problem I seem to be running into is that when my mod_perl filter
> runs, mod_cache has served up the headers of the file, but the content
> of the file is empty, so mod_perl has nothing to process.  Then
> somewhere down the line mod_cache must serve up the rest of the file.
> Do you know how this might be happening, or if it's just the way
> mod_cache operates?  Is there perhaps some interaction with mod_proxy
> where mod_cache only spits out the cached data at some particular
> point in the filter chain...
> I'm going to dig into mod_cache deeper now...
> Thanks!
> Adam

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