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. Cheers, Adam On Nov 29, 2007 2:27 PM, Adam Woodworth <mirkperl@xxxxxxxxx> wrote: > Hi Nick, > > Thanks for the response! > > > > 1 - mod_cache [..got 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:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|