Consider a type-map containing this entry: URI: hello.ext Content-Type: application/foo Suppose some config file or .htaccess file says: AddType application/bar ext mod_negotation and mod_mime will fight each other and neither will have a clear victory. A request with Accept: application/bar will not get hello.ext, and a request with Accept: application/foo will get hello.ext in a response that says Content-Type: application/bar! I think apache should be self-consistent. It shouldn't choose a file because it's one type and then return it as another type. The Content-Type: in the type-map, because it applies specifically to a single file, should override the AddType directive that applies generally to files with a certain extension. I don't know whether the hook order should be rearranged, or find_ct() should be altered to avoid clobbering data that mod_negotiation has already filled in. I don't know what priority/severity this is, so I left the defaults. Someone more experienced may want to adjust them. This probably affects many or all operating systems, but I observed it only on Linux.
I'm stumbling accross the same... it should be clearly documented which setting wins (and the whole isn't just a problem for the type, but also for encoding, language, etc.). Behaviour seems to be even more weird, AFAICS,... Namely Apache uses the values from the type-map, to match the Accept* headers.... but it serves the file based on what mod_mime says. I think it should only fall back to mod_mime, when there is no Content-Type given for a variance in the type-map... which makes sense IMHO, if one just wants to override e.g. the language.
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 an issue in 2.4.41. And the same issue as #55431.