javaapachehttpwebspheremod-deflate

mod_deflate with IBM WebSphere and IBM IHS

I'm trying to enable response compression for css, js and html resources that are bundled as part of a Web application deployed to WebSphere v7. All HTTP traffic is routed to an IBM IHS HTTP server sitting in front of the WebSphere instance.

I've created a mod_deflate.conf file and imported it into the httpd.conf file. Contents are as follows:

LoadModule deflate_module modules/mod_deflate.so

DeflateCompressionLevel 3

# Compress all content, manually excluding specified file types 
<IfModule mod_deflate.c>   
    # place filter 'DEFLATE' on all outgoing content       
    SetOutputFilter DEFLATE   
    # exclude uncompressible content via file type   
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip)$ no-gzip   
    <IfModule mod_headers.c>
        # properly handle requests coming from behind proxies
        Header append Vary User-Agent   
    </IfModule> 
</IfModule>

# deflate.log, log compression ratio on each request 
<IfModule mod_deflate.c>
    DeflateFilterNote Input instream
    DeflateFilterNote Output outstream
    DeflateFilterNote Ratio ratio
    LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    CustomLog logs/deflate.log deflate
</IfModule>

# Properly handle old browsers that do not support compression
<IfModule mod_deflate.c>
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

When I view the HTTP traffic, I see that requests specify that gzip/deflate encoding is acceptable:

Accept:"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
Accept-Encoding:"gzip, deflate"

However, the responses are not being compressed (no headers are being returned relate to gzip/deflate):

Content-Type:"text/html; charset=UTF-8"
Vary:"User-Agent"
Server:"IBM_HTTP_Server"

Also, the deflate.log does not show any compression happening:

"GET /webapp/css/style.css HTTP/1.1" -/- (-%)
"GET /webapp/js/jquery/jquery.ui.draggable.min.js HTTP/1.1" -/- (-%)
"POST /webapp/markup/Basic.xhtml HTTP/1.1" -/- (-%)

The Vary response header is being sent back, so it's definitely hitting the configuration block where the SetOutputFilter is declared.

What am I missing here -- isn't content compressed on-the-fly based on the filters/content type/resource name matches? In the above case, everything that doesn't match the regex .(?:gif|jpe?g|png|rar|zip)$ no-gzip should be compressed, no?

Solution

  • Playing this one by the numbers -- you looked at the original HTTP headers from the client and not the hedaers issued by WebSeal, and WebSeal decided to strip Accept-Encoding so it didn't have to itself worry about multiple variants of the same resource.

    The stripping is probably configurable in some obscure webseal way.