Okay, here's the bug:
org.apache.coyote.http11.Http11AprProcessor:1504:
response.getContentLengthLong() returns 4, instead of the true file
size, making it appear lower than the minimum compression threshold.
Alex Epshteyn wrote:
>
> Turned out it was the file size. If I arbitrarily trim the file to be
> just under 50 KB the compression will work.
>
> Looks like the Connector's compression facility is checking for an upper
> limit on stream length or something like that.
>
> Does anyone know of a way to disable this upper bound?
>
> Thanks,
> Alex
>
>
>
> Alex Epshteyn wrote:
>>
>> I finally had some time to try to track down this problem further. I set
>> the log levels to ALL, but still nothing useful showing up. However, I
>> found a curious thing in my access log. Consider this snippet:
>>
>> 76.19.64.19 - - [18/Apr/2008:04:29:37 +0000] "GET /theme.css HTTP/1.1"
>> 200 6360
>> 76.19.64.19 - - [18/Apr/2008:04:29:37 +0000] "GET
>> /B2200E18EF2035F53CA3D7E241122BB6.cache.html HTTP/1.1" 200 -
>>
>> The theme.css file is served up gzipped but
>> B2200E18EF2035F53CA3D7E241122BB6.cache.html is not! Notice the "-"
>> printed at the very end. The doc for the access log valve describes this
>> field as "Bytes sent, excluding HTTP headers, or '-' if zero". So the
>> access log thinks that zero bytes are being sent for this file.
>>
>> This is not true, as the file does get properly served, just not gzipped.
>> Seems like an indication of some other problem, though.
>>
>> Does anyone have any ideas?
>>
>> Here is the file itself if any of the contributors reading this would
>> like to try to debug. I'd try it myself, but I can't repro the problem
>> in my Windows dev environment - it only happens in my CentOS production
>> environment. (Hope the attachment worked - I'm writing this from
>> Nabble).
>>
>>
>> http://www.nabble.com/file/p16760347/B2200E18EF2035F53CA3D7E241122BB6.cache.html
>> B2200E18EF2035F53CA3D7E241122BB6.cache.html
>>
>> Here are the possible causes I can think of right now: 1) the file is too
>> big, almost 200 KB 2) the dual-extension, .cache.html 3) filename too
>> long. That's pretty much it. I don't think it's the contents inside the
>> file - I've gone through several incarnations of these (they are
>> generated by my compiler), and not a single one has successfully gotten
>> gzipped.
>>
>> Thanks again for your time,
>> Alex
>>
>>
>> Alex Epshteyn wrote:
>>>
>>> I have Tomcat's compression enabled:
>>>
>>> <Connector port="8080" maxHttpHeaderSize="8192"
>>> maxThreads="200" minSpareThreads="25"
>>> maxSpareThreads="75"
>>> enableLookups="false" redirectPort="8443"
>>> acceptCount="100"
>>> connectionTimeout="20000" disableUploadTimeout="true"
>>> compression="on"
>>> compressionMinSize="2048"
>>> noCompressionUserAgents="gozilla, traviata"
>>>
>>> compressableMimeType="text/html,text/xml,text/javascript,text/css"/>
>>>
>>> It works as expected for all my resources (stylesheets, scripts, etc)
>>> except for one static file, which has the extension .cache.html (in
>>> case you're wondering, it contains scripts generated by GWT). This
>>> file is pretty large - about 150K, but Tomcat doesn't compress it for
>>> some reason.
>>>
>>> Here are the response headers for this file (I have a custom filter
>>> that sets the cache headers prior to forwarding the request up the
>>> chain):
>>>
>>> Server Apache-Coyote/1.1
>>> Cache-Control public, max-age=315360000
>>> Expires Wed, 28 Mar 2018 18:58:38 GMT
>>> Etag W/"136900-1206809984000"
>>> Last-Modified Sat, 29 Mar 2008 16:59:44 GMT
>>> Content-Type text/html
>>> Content-Length 136900
>>> Date Sun, 30 Mar 2008 20:44:14 GMT
>>>
>>> Here are the response headers for a file that gets properly compressed
>>> (which also passes through the same filter):
>>>
>>> Server Apache-Coyote/1.1
>>> Pragma no-cache
>>> Cache-Control max-age=0, no-store, no-cache, must-revalidate
>>> Expires Thu, 01 Jan 1970 00:00:00 GMT
>>> Etag W/"4869-1206809984000"
>>> Last-Modified Sat, 29 Mar 2008 16:59:44 GMT
>>> Content-Type text/javascript
>>> Transfer-Encoding chunked
>>> Content-Encoding gzip
>>> Vary Accept-Encoding
>>> Date Sun, 30 Mar 2008 20:44:14 GMT
>>>
>>> I don't see any relevant errors in my log files. I'm using Tomcat
>>> 5.5.26 on Linux. As a strange twist, the file does get compressed
>>> properly with Tomcat 5.5.26 on Windows.
>>>
>>> Any ideas?
>>>
>>> Thanks in advance for your help!
>>>
>>> Alex
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Large-HTML-file-not-getting-compressed-despite-compression-enabled-tp16387385p16764917.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
