Nick Kew wrote: > On Mon, 06 Aug 2007 00:50:59 -0400 > Nikolas Coukouma <[EMAIL PROTECTED]> wrote: > >> Right now the inflate filter only checks to see if the >> Content-Encoding in the headers table contains gzip. It does not check >> r->content_encoding. This breaks it with mod_mime (among other >> things). >> > > Please refer to recent discussion, in particular > http://marc.info/?l=apache-httpd-dev&m=118622934222115&w=2 > and take a look at mod_deflate in /trunk/ and STATUS in 2.2. > Any thoughts there Thanks for the pointers; I wasn't sure what was worth reading ;)
I generally agree with you. mod_deflate has several problems, sadly, and it's sensible to take on one (or two) at a time. Althogh I glanced at the other mod_deflate tickets, I still haven't given much thought to them yet. For the content encoding issue .... Immediate (perhaps suitable for backport to 2.2.x?): Make all three mod_deflate filters use the check_gzip function for on the headers table. The output filters still check r->content_encoding; use another static function that does that common task and calls the check_gzip (or maybe have check_gzip take the request intead of the headers table and then a flag for checking input or output). (Sorry, I have some ants in my pants about making this at least mostly work in a relase or at least real-soon-trunk version. I don't know if that's feasible) Bit longer: (please excuse any ignorance on my part here) I like the idea of adding a phase/filter that would combine the (seemingly) legacy r->content_encoding with the header table. Precedence seems to be a bit of an issue (thoughts? new or old). For marvelous compatability, these fields could be mirrored after each filter. This seems worth attempting/fiddling-with in trunk; it would provide backwards compatability while ensuring that the headers table is usable. Alternatively, maybe the filters should be slowly updated to use accessor functions that would do the update lazily. This might be better from performance, but doesn't seem to really address (what I see as) the problem: there's two places to store the value for the same key. Even longer: My curent feeling is that, ultimately, content_encoding should be deprecated in favor of the request header tables. I imagine this would break a lot of third-party modules and I although I see it as desirable from where I am, I don't know if it's a good direction to head in. -Nikolas
