0

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?

Javaddict
  • 251
  • 2
  • 4
  • 12
  • Ok, I just noticed that the response header **Transfer-Encoding:"chunked"** is being returned in _some_ cases but not all. Apparently this can't be used with mod_deflate: [chunked transfer encoding](http://stackoverflow.com/questions/9039710/how-to-make-apache-mod-deflate-and-transfer-encoding-chunked-work-together?rq=1) – Javaddict Dec 08 '15 at 12:46

3 Answers3

1

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.

covener
  • 17,402
  • 2
  • 31
  • 45
  • Nice hint for debugging deflate: CustomLog logs/deflate-debug.log "%h %l %u %t \"%r\" %>s %b %D %{RH}e %{WAS}e %{Accept-Encoding}i %{Content-Type}o %{Content-Encoding}o %{Via}i %{no-gzip}e %{remote}p" – covener Dec 09 '15 at 16:07
  • Thanks, this is likely the case -- WebSeal isn't passing the "accept-encoding" request header. That would explain why the mod_deflate logs didn't show any compression happening on the responses when the requests were coming from Webseal. – Javaddict Dec 10 '15 at 17:01
0
1. Uncomment
LoadModule deflate_module modules/mod_deflate.so
2. Add 
<IfModule mod_deflate.c>
    <Location / > <!-- you can specify your app URL also-->
        # Space separated mime types.
        AddOutputFilterByType DEFLATE text/html text/plain application/json 
    </Location>
</IfModule>
Ahmed
  • 184
  • 7
  • Thanks, specifying a location and a filter by content type is the initial route that I took. When I saw that compression wasn't being applied, I tried a less restrictive setting by defining SetOutputFilter for all requests (which still didn't work). – Javaddict Dec 08 '15 at 12:42
  • I tested this in web sphere 7 – Ahmed Dec 08 '15 at 13:31
  • did you restart the server after adding all the configurations – Ahmed Dec 09 '15 at 10:09
  • IHS yes, WebSphere no. The configuration updates are definitely being picked up because the deflate log is being generated (whereas I never had it before) _and_ the Vary response header is being returned. Also, I believe my original setting is less restrictive since it enables compression for all content types regardless of the location _except_ for images/rar/zip. Was your Web content contained in an EAR/WAR file deployed to WebSphere? – Javaddict Dec 09 '15 at 14:22
0

Ok, I finally was able to troubleshoot the root cause. We are accessing the Web application via an IBM WebSeal front-end proxy.

When I bypassed the WebSeal and accessed the application directly, the following HTTP response header was returned:

Content-Encoding:"gzip"

So, now I have to troubleshoot why the content is being decompressed before going back to the client.

Javaddict
  • 251
  • 2
  • 4
  • 12