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

[Alex <adm...@ah...>]

Hi Christian,

Thank you for the followup. There is no reverse proxy setup in place, 
modsecurity is running on the application server. Does this change 
anything?

Kind Regards,
Alex.



On 2015-10-19 14:23, Christian Folini wrote:

> 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