On Tue, Feb 24, 2009 at 10:27 PM, Roy T. Fielding <[email protected]> wrote:
> I spent a while looking at mod_deflate and various filter related > issues in 2.2.x/trunk, but I had to context switch away before > I could create such a large fix. This message is to write > down my conclusions so that I can remember them and maybe fix > the silly thing when I get a chance, or maybe encourage someone > else to do it in the meantime. > > The current state is broken. There is no other way to describe it. > mod_deflate is adding -gzip to the end of etags in order to be > correct in regard to variants, but ap_meets_conditions() is not > aware of the -gzip addition; in fact, etags are compared before > the output filter is even initialized for a given response, so > there is no way for ap_meets_conditions() to work without resorting > to stupid hacks like always checking for "foo" and "foo-gzip" in > the core (even the hack is difficult without completely rewriting > how etags are compared). > > Roy, For what its worth (maybe to confirm your observations?), while trying to track down a memory leak with mod_perl, I noted that Apache started using a little more memory for every request only when mod_deflate was enabled. http://www.docunext.com/blog/2008/06/24/even-more-perl-notes/ And to sing the praise of filters, I believe them to be a very good thing for dynamic content generation. And, even if its not the most efficient, mod_ext_filter is a sweet one. - Albert
