Bug 43622 - compression / minCompressionSize attribute not properly implemented
Summary: compression / minCompressionSize attribute not properly implemented
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP (show other bugs)
Version: 5.5.12
Hardware: All All
: P3 minor with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 03:51 UTC by redeemer
Modified: 2008-01-06 15:13 UTC (History)
0 users



Attachments
Test cases with different connector settings (2.00 KB, text/plain)
2007-10-15 03:55 UTC, redeemer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description redeemer 2007-10-15 03:51:24 UTC
2 of the compression related attributes for the http connector are:

compression = on | off | force | <integer val>
The documentation states that integer val will be implemented as:
compression="on" and minCompressionSize = <integer val>

minCompressionSize = <integer val>
(The documentation for 5.5.12 doesnt mention this at all, but read this in the
server.xml)

The problem is that the documenation gives the impression that only setting
compression="some integer val" is sufficient, however the way the code is
written, the value of "minCompressionSize" always overrides the value specified
in the "compression" field. Even if minCompressionSize isnt set, it will still
get the default value of 2048 and override whatever value was there in the
"compression" field.

I looked at the implementation of the http11 connector and found the following
code that might be the culprit:

In org.apache.coyote.http11.Http11BaseProtocol.Http11ConnectionHandler.init
    processor.setCompression( proto.compression );
    processor.setCompressionMinSize( proto.compressionMinSize);

since the "setCompressionMinSize" is called after compressionMinSize, its value
will override the value read from compression atttribute.


I have looked at the code for Tomcat 6.0 also, and the problems appears to still
be present.
Comment 1 redeemer 2007-10-15 03:55:31 UTC
Created attachment 20977 [details]
Test cases with different connector settings

These test cases can prove that either the documentation or the code needs to
be changed regarding the compression size settings
Comment 2 redeemer 2007-10-18 06:25:38 UTC
There is a mistake with the attribute name, it is compressionMinSize, not
minCompressionSize

(In reply to comment #0)
> 2 of the compression related attributes for the http connector are:
> 
> compression = on | off | force | <integer val>
> The documentation states that integer val will be implemented as:
> compression="on" and minCompressionSize = <integer val>
> 
> minCompressionSize = <integer val>
> (The documentation for 5.5.12 doesnt mention this at all, but read this in the
> server.xml)
> 
> The problem is that the documenation gives the impression that only setting
> compression="some integer val" is sufficient, however the way the code is
> written, the value of "minCompressionSize" always overrides the value specified
> in the "compression" field. Even if minCompressionSize isnt set, it will still
> get the default value of 2048 and override whatever value was there in the
> "compression" field.
> 
> I looked at the implementation of the http11 connector and found the following
> code that might be the culprit:
> 
> In org.apache.coyote.http11.Http11BaseProtocol.Http11ConnectionHandler.init
>     processor.setCompression( proto.compression );
>     processor.setCompressionMinSize( proto.compressionMinSize);
> 
> since the "setCompressionMinSize" is called after compressionMinSize, its value
> will override the value read from compression atttribute.
> 
> 
> I have looked at the code for Tomcat 6.0 also, and the problems appears to still
> be present.

Comment 3 Mark Thomas 2007-11-30 11:17:11 UTC
Thanks for the report. This is fixed in trunk and proposed for 6.0.x and 5.5.x

Comment 4 Mark Thomas 2008-01-06 15:13:58 UTC
Fixed in 5.5.x and will be included in 5.5.26 onwards.