UPDATE: Ivan Ristic implemented SecDisableBackendCompression in trunk. With this directive, you don’t need the hack below. See my post to the list.
One of cryptic warnings found in ModSecurity audit.log is
[msg "ModSecurity does not support content encodings"]
Clearly, it says ModSecurity doesn’t support content encodings. That is, it cannot inspect gzipped content. This is problematic especially when ModSecurity is running on reverse proxy. The question is, “how can I inspect, then?” There are some very useful advice from the developer in the list archive. Bad news is, it doesn’t work. Some claims it worked, but they skip deflate process by SetEnvIfNoCase, which is not an option for me.
My goal is:
- Compress by Content-Type, not by file extension because sometime file extension is not available (/foo.php?imageid=1234). You cannot use SetEnvIfNocase because it cannot access to response headers.
- Do not compress images, video and other pre-compressed files (compress all except a few others).
- Do not compress before ModSecurity inspect the content (the goal).
After hours and days to find why it doesn’t work, I finally found the problem. In modextfilter.c, it looks for ext filter by f->frec->name, which is not the name of ext filter but FilterProvider’s name when it should have looked for it by “nodeflate” in my case.
583 /* look for the user-defined filter */ 584 ctx->filter = find_filter_def(f->r->server, f->frec->name);
I’m not an apache guru in any way, I might be wrong.
- Even though configtest doesn’t complain, ExtFilterDefine is only valid in server config context
- DO NOT “SetOutputFilter DEFLATE”. It compresses all contents, ignoring nodeflate
- Define two ext filters
Here is the WORKING config.
I tested this on FreeBSD, so, use “cmd=/bin/true” on Linux and others (“/bin/sh” should work and is more portable, if you prefer).
When Apache 2.4 is released, it will be much simpler. See “Expression parser for Apache”.