#19 Dechunk doesn't work with Client-Transfer-Encoding
mod_gzip stopped compression ColdFusion output when I
upgraded from ColdFusion 4.5.1 to ColdFusion MX 6.1
(the later uses JRun as its engine).
This configuration works A-1:
Apache 1.3.31, mod_gzip 1.3.26.1a, ColdFusion 4.5.1
This one doesn't work with the same ColdFusion files:
Apache 1.3.31, mod_gzip 1.3.26.1a, ColdFusion MX 6.1
They both use the exact same httpd.conf and mime.types
files.
After a couple of hours of searching the web and
testing various Apache/mod_gzip configurations, I
concluded the problem was caused by the
"Client-Transfer-Encoding" header, which prevents
mod_gzip from processing the output. As I understand
it, mod_gzip_dechunk expects to find
"Transfer-Encoding: chunked" and not
"Client-Transfer-Encoding: chunked" in order to removed
the header, agglomerate the chunks and compress the output.
Here are the two traces:
=== response for setup working correctly ===
[ 15] HTTP/1.0 200 OK
[ 17] Connection: close
[ 35] Date: Wed, 11 Aug 2004 06:13:25 GMT
[ 48] Server: Apache/1.3.31 (Win32) mod_gzip/1.3.26.1a
[ 7] Vary: *
[ 22] Content-Encoding: gzip
[ 20] Content-Length: 2458
[ 23] Content-Type: text/html
[ 30] Page-Completion-Status: Normal
[ 30] Page-Completion-Status: Normal
[ 72] Set-Cookie: CFID=220493; expires=Sun, 27-Sep-2037
00:00:00 GMT; path=/;
[ 77] Set-Cookie: CFTOKEN=39897249; expires=Sun,
27-Sep-2037 00:00:00 GMT; path=/;
Client-Date: Wed, 11 Aug 2004 06:14:19 GMT
Client-Response-Num: 1
=== response for setup not compressing outpout ===
[ 15] HTTP/1.0 200 OK
[ 17] Connection: close
[ 35] Date: Wed, 11 Aug 2004 06:51:36 GMT
[ 57] Server: Apache/1.3.31 (Win32) JRun/4.0
mod_gzip/1.3.26.1a
[ 23] Content-Language: en-US
[ 38] Content-Type: text/html; charset=UTF-8
[ 65] Set-Cookie: CFID=221;expires=Fri, 04-Aug-2034
06:51:03 GMT;path=/
[ 73] Set-Cookie: CFTOKEN=55172318;expires=Fri,
04-Aug-2034 06:51:03 GMT;path=/
Client-Date: Wed, 11 Aug 2004 06:51:37 GMT
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Is there a way to configure mod_gzip to process output
from the second setup correctly, or will this need to
be corrected in the source code for a future release?
Any other alternative I might consider?
Thanks!
Giuseppe Fortino
Logged In: YES
user_id=211909
I cannot seem to find a header named
"Client-Transfer-Encoding" in the HTTP 1.1 specification
(RFC2616) which is what mod_gzip tried to be complient to.
Logged In: YES
user_id=25804
Change your mod_gzip "include" line from:
^text/html$
to:
^text/html
This is because it's a regular expression, and in the first
example it will match on "[ 23] Content-Type: text/html",
but in your upgraded server it's line has changed to "[ 38]
Content-Type: text/html; charset=UTF-8".
The "; charset=UTF-8" added by your server upgrade stops the
original configuration from matching, thus the change needed
as described above.
Hope that helps.
:)
Regards and best wishes,
Justin Clift
Logged In: YES
user_id=211909
> This one doesn't work with the same ColdFusion files:
> Apache 1.3.31, mod_gzip 1.3.26.1a, ColdFusion MX 6.1
> They both use the exact same httpd.conf and mime.types
> files.
But as vapour correctly pointed out, your ColdFusion engine
now sends additional information (character set name) in the
"ContentType" header, and thus your "mod_gzip_item_include"
rule is a likely candidate for being too strict now. (We
can't be sure though unless you post your mod_gzip
configuration rules.)
Read
http://www.schroepl.net/projekte/mod_gzip/config.htm#filters
for a detailled description why this charset makes a difference.
You'll probably want this additional charset information
being sent (if you want to use UTF-8 special characters),
therefore modifying the mod_gzip configuration according to
your new requirements is the correct thing to do (although
you might possibly be able to turn off this charset in the
ColdFusion configuration as well).
Of course you could also use HTML entities for any special
characters and then be independent of any character
encoding, but that's your decision.