When mod_deflate is used to inflate, it must adjust the request headers (e.g. it needs to remove the "Content-Length" header and adjust the "Content-Encoding" header). Currently mod_deflate adjusts the headers when the request body is read. But this is too late. For example, if a content generator module needs to look at the request headers before reading the request body, the content generator module "sees" the old (unmodified) headers. mod_deflate should adjust the headers in an early stage, for example in a fixup hook (ap_hook_fixups). I assume that some other bugs are also caused by this issue, e.g. bug 52595.
Created attachment 33774 [details] Proposed patch: Adjust the headers in a filter init function I have created a patch that fixes the problem. I hope that someone finds time to review it.
This looks like the bug I've been trying to figure out - in my case resulting in mod_proxy blowing up and returning an error because the content-length header doesn't match the (deflated) length of the actual content. It's not immediately obvious to me why your patch fixes this - it plausibly fixes the Content-Encoding header (because that gets removed in check_gzip), but the Content-Length header (and Content-MD5, though I don't think anything much looks at that!) are still removed in the same place they were previously. Did I miss something or does the patch need to have that added?
Created attachment 36068 [details] Make mod_deflate handle sub-requests too Don't know if this one solves your specific problem (which is based on the same one as mine), nor if it's gonna break some other modules, nor if it's a generic-enough solution, but this solves the problem of "SetInputFilter DEFLATE" (deflate in) when using with mod_rewrite (internal rewrite). Now, content is decompressed (Content-Encoding and Content-Length are eaten correctly). Solution: make mod_deflate handle sub-requests too.