I am observing that mod_mime sets the mimetype based on the results that mod_negotation returns from a type-map. I would expect that mod_negotation would force the headers set by the type-map (especially so for mime-type). Specific case is for gzipped content. I.e. my type map "foo.var" lists two variants: "bar.css" and "bar.css.gz" I observed that "bar.css.gz" is being served with a mime-type based on the .gz extension instead of the "text/css" explicitly listed in the "foo.var" type map. I would expect that mod_negotation force the "text/css" mimetype. Is this intentional?
First .gz shouldn't be a Content-Type, but a Content-Encoding... check your mod_mime config ;) 2nd, isn't this similar/the same than bug #41130?
(In reply to Christoph Anton Mitterer from comment #1) > First .gz shouldn't be a Content-Type, but a Content-Encoding... check your > mod_mime config ;) > Hrm, yes I guess I suppose so. However, it appears that "application/gzip" or "application/x-gzip" is the actual mimetype for gzipped files. A quick google search turned up this: http://tools.ietf.org/id/draft-levine-application-gzip-03.html and this http://en.wikipedia.org/wiki/Gzip although I realize one source is a draft and the other is wikipedia... But this was set automatically on Amazon Linux it seems. That aside, the whole point is that it would make the most sense that the Content-Type listed in the type-map takes priority, otherwise, what is the point in listing it anyways? Since I am explicitly listing a mime-type it would seem that my knowledge of whats in the file should have greater weight than a extension mapping. > > 2nd, isn't this similar/the same than bug #41130? Wow, yes. From 2006... I guess that means I am overlooking something obvious because nobody has been interested in fixing it for 7 years. Is the recommended solution here not to have file extensions on the files a type map points to or something?
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.
This is still a problem in 2.4.41. And yes, this is the same issue as 41130 from 2006. As I see - based on stackoverflow - there are people who interested in a working type map or multiviews, because that would be a correct solution to serving precompressed documents. Instead of the currently recommended horrible - and wrong - mod-rewrite hack described in the documentation for mod_deflate. But multiviews does'n work either, see #60619.
By the way .gz is a valid MIME type. It is also a valid content encoding. Serving a document with Content-Type gzip is useful, it means that this is a gzipped something, after download you should gunzip it. Serving a document with gzip Content-Encoding is also useful, it means that your document was transferred in compressed state, but you get an uncompressed document in your browser, ready for use. Serving a document with both Content-Encoding gzip and Content-Type gzip is usually incorrect. In the best case this means that a gzipped file is transferred by gzipping again. In the actual case it is just an invalid response: a gzipped file transferred using content-encoding gzip is not a gzip document on the browser side, becaue the brower alredy decompressed it!