Bug 43830 - mod_deflate inconsistently compresses dynamic output from mod_jrun20 based on DirectoryIndex
Summary: mod_deflate inconsistently compresses dynamic output from mod_jrun20 based on...
Status: RESOLVED INVALID
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_deflate (show other bugs)
Version: 2.0.61
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-09 11:40 UTC by Brian G
Modified: 2007-11-12 06:43 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian G 2007-11-09 11:40:01 UTC
Mod_jrun20.so is a module provided by Adobe for the ColdFusion product.  It is
very similar to PHP, Ruby, etc.  When enabling mod_deflate, only SOME dynamic
content is compressed while all static content is compressed.

I have enabled gzip compression with the following configuration:

<Location />
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript
text/xml application/x-javascript
</Location>

I am unable to use SetOutputFilter DEFLATE with exceptions as we use ColdFusion
to generate files dynamically like PDF, SWF and JPG that cannot be compressed.

Using the AddOutputFilterByType, CSS and Javascript are compressed but HTML and
XML returned from ColdFusion is not.

With the help of rici on #apache, we tried adding the following configuration
options:

    AddType text/html .cfm
    AddOutputFilter DEFLATE cfm

First one at a time and then both together.  Here is where things turn
inconsistent.  Situations under which text/html is returned properly:

 * HTTP/1.0 requests
 * HTTP/1.0 or /1.1 requests that do not include a specific filename but resolve
to a ColdFusion file by way of "DirectoryIndex index.cfm".
 
All other HTML and XML pages are returned without compression.  This is verified
by way of Firefox's LiveHTTPHeaders and third party site WebSiteOptimization.com.

I have enabled deflate logging that includes the initial and final response
status as well as the mime type to verify that these are being seen correctly. 
Here are some examples from the log where it is working.  Non-HTML content (CSS/JS):

[09/Nov/2007:10:22:55 -0800] 200 200 text/css GET /bits/css/pap.css HTTP/1.1
4792 19638 24
[09/Nov/2007:10:26:05 -0800] 200 200 application/x-javascript GET
/bits/library/jquery/1.2.1/jquery.js HTTP/1.1 14437 46179 31

text/html in both 1.0 and 1.1 without referencing the filename:

[09/Nov/2007:10:18:04 -0800] 200 200 text/html GET / HTTP/1.1 3352 9877 33
[09/Nov/2007:10:23:16 -0800] 200 200 text/html GET / HTTP/1.0 3352 9877 33
[09/Nov/2007:10:25:55 -0800] 200 200 text/html GET /pmp/ HTTP/1.1 1311 2959 44

And instances where it is not.  GET with the filename specified:

[09/Nov/2007:10:18:24 -0800] 200 200 text/html GET /index.cfm HTTP/1.1 - - -
[09/Nov/2007:10:26:04 -0800] 200 200 text/html POST /pmp/index.cfm HTTP/1.1 - -  -
[09/Nov/2007:10:26:14 -0800] 200 200 text/xml GET /calendar/rss.cfm?type=rss HTT
P/1.0 - - -

There may be something done incorrectly in Adobe's mod_jrun module w/r/t adding
output filters however the fact that DirectoryIndex influences the results here
indicates to me something else is going on and why I'm filing this bug.

I have the mod_jrun source available and can upload it if desired.
Comment 1 Brian G 2007-11-09 11:43:59 UTC
Created attachment 21107


The mod_jrun20.so source code.	Note that both Apache 1.3 and 2.0 modules are
in this zip; mod_jrun20.c is the 2.0.x version.
Comment 2 Ruediger Pluem 2007-11-09 14:37:04 UTC
This is a bug in mod_jrun. They are not calling ap_set_content_type to set the
content type but they assign the value directly to r->content_type.
Please do NOT attach data for which you do NOT own the copyright.