tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Epshteyn <alexander.epsht...@gmail.com>
Subject Re: Large HTML file not getting compressed despite compression enabled
Date Fri, 18 Apr 2008 20:11:03 GMT

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message