Re: [mod-security-users] issue with response body processing

[Christian F. <chr...@ti...>]

Alex,

Your problem is a typical one.

Are you running ModSec on a reverse proxy or on the application
server itself?

The SecDisableBackendCompression is the standard way to handle it
and it works just fine on a Reverse Proxy (if the backend
application is well-behaving).

The idea is to have the backend send the response uncompressed
to the apache reverse proxy and then have apache do the
compression of the response before it is sent to the client.
This can be done via
LoadModule              deflate_module          modules/mod_deflate.so
...
SetOutputFilter         DEFLATE

You may want to look into AddOutputFilterByType, but this could
potentially open a can of worms with timing issues and stuff.
This has been a topic in the developer community lately and maybe
we will see an improvement. My personal approach for selective
compression of certain content type is to work with the following
construction:

SecRule RESPONSE_HEADERS:Content-Type   "^(text/html|text/plain|text/xml|text/css|text/javascript|application/javascript)$" "phase:3,pass,nolog,id:1,t:lowercase,setenv:do-gzip"
SecRule &ENV:do-gzip "@eq 0" "phase:3,pass,nolog,id:2,setenv:no-gzip"

The deflate module checks the env variable no-gzip. We check the
content type and set an additional env variable do-gzip if it is
something we want to compress. It if it is not set (number of ENV 
variables set equals 0), we do not want compression and set the 
no-gzip variable.

Good luck,

Christian


-- 
The scientist has marched in and taken the place of the poet. But one
day somebody will find the solution to the problems of the world and
remember, it will be a poet, not a scientist.
-- Frank Lloyd Wright