Mod_gzip – how to make configuration work for Apache 1.3, mod_jk and JBOSS/JSF

I’ve been working a couple of days trying to get mod_gzip to work with apache 1.3, enabling compression for JSF application (.faces). Everything seemed so easy in the configuration described here, but I actually troubled quite a lot with it, and wanted to share what I’ve learned. 🙂 I used this page as a starting point for my digging into mod_gzip. I use mod__jk to forward the request to jboss’ tomcat server.

Firs and most important of all, the configuration I use that make things work with JSF:

LoadModule gzip_module     libexec/mod_gzip.so

<IfModule mod_gzip.c>
mod_gzip_on                   Yes
mod_gzip_can_negotiate        Yes
mod_gzip_static_suffix        .gz
AddEncoding              gzip .gz
mod_gzip_update_static        No
mod_gzip_command_version      '/mod_gzip_status'
mod_gzip_temp_dir             /tmp
mod_gzip_keep_workfiles       No
mod_gzip_minimum_file_size    300
mod_gzip_maximum_file_size    500000
mod_gzip_maximum_inmem_size   60000
mod_gzip_min_http             1000
mod_gzip_handle_methods        GET POST
mod_gzip_dechunk              Yes
mod_gzip_send_vary            On

#Files and items to compress
mod_gzip_item_include         file       \.html$
mod_gzip_item_include         file       \.htm$
mod_gzip_item_include         file       \.js$
mod_gzip_item_include         file       \.js
mod_gzip_item_include         file       \.faces
mod_gzip_item_include         file       \.css$
mod_gzip_item_include         file       \.jsp$
mod_gzip_item_include         file       \.jsp

mod_gzip_item_include         uri        \.jsp$
mod_gzip_item_include         uri        \.jsp

mod_gzip_item_include         handler    \.*
mod_gzip_item_include         handler    \.*$

mod_gzip_item_include         mime       ^text/html$
mod_gzip_item_include         mime       ^text/html
mod_gzip_item_include         mime      ^text/plain
mod_gzip_item_include         mime      ^text/plain$
mod_gzip_item_include         mime       ^text/xml$
mod_gzip_item_include         mime       ^text/css$
mod_gzip_item_include         mime       ^text/javascript$
mod_gzip_item_include         mime       ^text/javascript
mod_gzip_item_include         mime       ^application/x-javascript$
mod_gzip_item_include         mime       ^application/javascript$

CustomLog                     logs/mod_gzip.log common_with_mod_gzip_info2
LogFormat                     "%h %l %u %t \"%V %r\" %<s %{Content-type}o  %b mo
d_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n -< Out:%{mod_gzip_output_
size}n = %{mod_gzip_compression_ratio}n pct." common_with_mod_gzip_info2
</IfModule>

I will just say (cause it is important) that without the two lines including the “handler” patterns, I couldn’t get any compression to work when I was playing with JSF applications. All the logging lines had status “DECLINED:EXCLUDED”.

The first thing to do when you’re supposed to do this would be to enable logging of gzip to understand what is going on. Then based on status-codes you can get a clue to why a file is compressed or not.

Add the following line in your conf:
LogFormat “%h %l %u %t \”%V %r\” %<s %b mod_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n -< Out:%{mod_gzip_output_size}n = %{mod_gzip_compression_ratio}n pct.” common_with_mod_gzip_info2

A problem that troubled me were when I got prints like this:
213.162.235.138 – – [21/Aug/2008:15:13:44 +0200] “localhost.localdomain GET /Url/css/styles.css HTTP/1.1” 200 text/plain 0 mod_gzip: SEND_AS_IS:NO_200 In:0 -< Out:0 = 0 pct.

Apache reports the file as 200, but gzip ends up with status code “SEND_AS_IS:NO_200”. Ok, so we go to check the meaning of the status codes, but that didn’t tell us much. Confusing? It really means that this file is cached in the browser, and will not be compressed because of this. Try ctrl+F5 to clear the cache, then it should compress that file as well.

Also, even if I included the line “mod_gzip_item_include file \.js$” to compress javascript, for all the javascripts it reported “SEND_AS_IS:RESPONSE_CONTENT_TYPE_EXCLUDED”
I troubled with this one, but then I remembered something I read on the internet: “The order of processing during each of both phases is not important, but to trigger the compression of a request’s content this request a) must match at least one include rule in each of both phases and # b) must not match an exclude rule in any of both phases.”

In other words, for some reason it didn’t find an include rule for javascript in both phases. I had included mime type ^text/javascript, so I couldn’t understand this. But I felt like navigating blindly, cause I never saw what mime-type the request was. So I added the following to my log statement: “%{Content-type}o” – which would print out the mime-type as well. Then I saw that for some javascripts the mime-type were application/x-javascript. I included this in the include-list as well, then case was closed 🙂

Hope this post will help others in the same situation, or at least it might give you a clue to what is going on 🙂

Advertisements

2 Responses to “Mod_gzip – how to make configuration work for Apache 1.3, mod_jk and JBOSS/JSF”

  1. Fredrik Says:

    Synes det begynner å bli noe lenge siden forrige post nå, Eivind..

  2. Client performance: adding gzip compression « Dmitko.ru Says:

    […] Here is my mod_gzip configuration file (thanks to this post): […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: