Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 43191] compressableMimeType attribute ignored
In-Reply-To: <bug-43191-78@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20080701171126.82A7F234C148@brutus.apache.org>
Date: Tue,  1 Jul 2008 10:11:26 -0700 (PDT)

https://issues.apache.org/bugzilla/show_bug.cgi?id=43191


Jonathan Leech <jleech@virtela.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jleech@virtela.net


--- Comment #11 from Jonathan Leech <jleech@virtela.net>  2008-07-01 10:11:24 PST ---
For such a simple concept, every compression filter I have ever seen has
serious problems. Mostly the problems are not addressed, and instead all kinds
of finely grained mechanisms are created to more selectively apply compression.
For example, if a response sets the content-length header, I have seen
compression filters break. The browser either hangs waiting for the rest of the
response, or the response is truncated to the length set. I don't remember if
Tomcat's compression filter is guilty of this behavior or not, but I suspect
the latter due to the existence of the compressionThreshold setting. 

I have created my own GZIPFilter which addresses all the problems I have seen
in various other compression filter implementations. I am posting it as an
attachment to this bug, feel free to use it, or not. Its advantages are
captured in the comments, in summary, it streams rather than makes a copy, it
handles content-length correctly, it detects client support of gzip
compression, and it doesn't double compress. It is not problem-free, the known
problems and limitations are also captured in the comments.

My theory on filter mapping is to keep it simple. So my filter doesn't care
about mime-types, or any other qualification other compression filters use to
decide whether to compress or not. As I stated before, it is my experience that
these features exist to "fix" other problems in the filters.

The original poster can use my GZIPFilter in one of a few ways:
1) Use filter-mapping to selectively compress content.
2) Extend GZIPFilter, look at the mime-type header, and compress or not by
calling super.doFilter().
3) Modify my GZIPFilter to look at mime-types.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org