Bug 37834 - compressableMimeTypes not working properly
Summary: compressableMimeTypes not working properly
Status: RESOLVED DUPLICATE of bug 43191
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP (show other bugs)
Version: Unknown
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-08 05:27 UTC by fern@alum.mit.edu
Modified: 2007-08-29 04:48 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fern@alum.mit.edu 2005-12-08 05:27:48 UTC
the compressibleMimeTypes option for the Http Connector is buggy in that it only
allows you to add mime types to the default list, but does not allow you to
override the whole list ( remove default ones ).

So even if I set compressibleMimetypes = "one/type" the connector would behave
as if I had used "text/html,text/xml,text/plain,one/type".

The problem lies in Http11Processor prefilling the compressibleMimeTypes array
with the defaults, and the setCompressibleMimeTypes method not remove them, but
add them.

Possible solutions:
1) Have that array default empty.  This can work because the parent/using class,
Http11Protocol already has the mimetypes within its defaults.
2) Have setCompressibleMimeTypes method empty out the array, as probably expected.


Background:
Http Compression is a HUGE win for production environments.  But there is a bug
in IE's handling, that causes it to not decompress content when plugins (flash)
ask for it.  So those plugins (flash) are stuck with unexpectedly compressed
content, bringing your web application to malfunction.

Our hope was to turn off compression only for our xml files, so that our flash
application could download them appropriately.
Comment 1 Yoav Shapira 2006-04-13 20:58:06 UTC
Mmmm, you're absolutely right that setCompressibleMimeTypes should reset the
array to whatever argument is provided, not append the argument to pre-existing
types.  But changing this now would be a possible regression for a lot of users
;(  Not sure what to do, deferring handling for now.
Comment 2 Mark Thomas 2007-08-29 04:48:14 UTC
Marking this as a dup as the newer bug has a patch.

*** This bug has been marked as a duplicate of 43191 ***