Bug 38330 - Cannot RemoveType which comes from mime.types
Summary: Cannot RemoveType which comes from mime.types
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_mime (show other bugs)
Version: 2.0.52
Hardware: PC Linux
: P2 normal with 5 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2006-01-20 13:39 UTC by Adrian Vogel
Modified: 2010-04-12 05:40 UTC (History)
2 users (show)



Attachments
patch to make RemoveType override the info from TypesConfig (1.45 KB, patch)
2008-10-31 16:44 UTC, Stefan Fritsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Vogel 2006-01-20 13:39:45 UTC
It seems you cannot unassign a MIME type from a filename extension (with
RemoveType) which has been declared in the "mime.types" file. Removing types
which have been declared using AddType before works fine.

We wanted to turn ".gz" into an encoding instead of a type, but we weren't able
to do so before commenting out the declaration of "application/x-gzip" inside
"mime.types" (even though modifying that file is discouraged in the manual).
Might it be worthwhile to mention that our "mime.types" file is not located
inside the ServerRoot, but that TypesConfig accepts the absolute path
"/etc/mime.types"?

Is this behaviour intended? The manual does not go into detail on that, but I
think one should be able to remove default type associations from "mime.types"
as well.

Cheers, Adrian
Comment 1 Adam M. Costello 2006-11-29 12:52:06 UTC
I also want .gz to be an encoding, not a type, and .gz does *not* appear in my
mime.types, and still I was unable to use RemoveType .gz to counteract the
AddType in apache2.conf.  I had to comment out the AddType.  I'm using Debian
package apache2.2-common 2.2.3-3.1 with apache2-mpm-worker 2.2.3-3.1.

What's even stranger is that the filename extension should have been irrelevant,
because I was using a type map:

URI: home

URI: home.html
Content-Type: text/html; qs=1

URI: home.html.gz
Content-Type: text/html; qs=1
Content-Encoding: gzip

A request for home.var would yield a content-type of application/x-gzip, which
isn't even mentioned in the type map.  Similarly, if I changed the content-tpe
in the .var file to foo/bar, I would still get text/html.  Surely the explicit
instructions in home.var should override any filename-based type/encoding
determination.
Comment 2 Stefan Fritsch 2008-10-31 16:44:50 UTC
Created attachment 22817 [details]
patch to make RemoveType override the info from TypesConfig
Comment 3 Geoff Keating 2009-04-08 17:14:11 UTC
As a workaround, you can of course use .gzip, or anything other than .gz, to indicate the content-encoding.  This also helps for related problems you may encounter in browsers and filesystems.
Comment 4 Alberto González Palomo 2009-07-08 09:08:11 UTC
This also causes problems when using MultiViews for content language negotiation, as such files as "index.html.es" (Spanish version of index.html) are served as "application/ecmascript", and there is apparently no way to correct it from .htaccess files.
Comment 5 Stefan Fritsch 2009-10-03 05:16:06 UTC
Fixed in trunk in r821298
Comment 6 Stefan Fritsch 2010-04-12 05:40:01 UTC
fixed in 2.2.15