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
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.
Created attachment 22817 [details] patch to make RemoveType override the info from TypesConfig
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.
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.
Fixed in trunk in r821298
fixed in 2.2.15