Apache – How to Disable HTTP Compression (mod_deflate) When SSL Stream is Compressed

apache-2.2compressionhttpsssl

I found that Goggle Chrome supports ssl compression and Firefox should support it soon.

I'm trying to configure Apache to to disable http compression if the ssl compression is used to prevent CPU overhead with the configuration option:

SetEnvIf SSL_COMPRESS_METHOD DEFLATE no-gzip

While the custom log (using %{SSL_COMPRESS_METHOD}x) shows that the ssl layer compression method is DEFLATE, the above option did not work and the http response content is still being compressed by Apache.

I had to use the option:

BrowserMatchNoCase ".*Chrome.*" no-gzip

I prefer if there is more general method in case other browsers support ssl compression in future or someone has a version of Chrome that does not have ssl compression.

Best Answer

Now after I got more information about the problem, I should answer my own question. This is a reported bug in Apache; Bug 49057 - setenvif should have access to SSL environment variables.

The bug is fixed in Apache 2.4.1 but this is not an option as I'm using CentOS 6.x.

I'll see if I can set no-gzip environment variable through the application instead of the Apache config.

Related Solutions

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Ok, I think we've figured it out...

On the client side, Squid 2.5 and earlier doesn't understand "Transfer-encoding: chunked", so it delivers each chunk as the entire client request. Since it's only 1 chunk of the entire compressed request, it's invalid data and can't be read by the browser. (Not sure if this is an issue with other proxies)

On the server side, IIS always sends chunked encoding for Dynamic Compression (since IIS doesn't cache application responses, it has to compress each response on the fly, hence the chunked encoding).

The only way we can think of to fix this is to completely disable compression for HTTP 1.0 clients and only compress for HTTP 1.1 responses. The drawback is that anyone behind a proxy that sends 1.0 requests won't get compressed data and the site will load 0.5 - 1 second slower for those users.

Changes made in the metabase.xml file:

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

If anyone has a better solution, please let me know!

Concatenating gziped Apache logs

The gzip man page should have what you want, but you can concatate them directly:

cat file1.gz >> file2.gz
gzip -c file1 >> file2.gz

Compression is not as good as if it was just one file compressed, but you can recover with:

zcat old.gz | gzip > new.gz

Best Answer

Related Solutions

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Concatenating gziped Apache logs

Related Topic