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
|