[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

Ben Hoyt report at bugs.python.org
Thu Apr 18 02:27:55 CEST 2013


Ben Hoyt added the comment:

Okay, I'm looking at the diff between mt-tip-noregistry.txt and mt-tip-newregistry.txt, and I've attached a file showing the lines that are *different* between the two, as well as the Apache mime.types value for that file extension.

In most cases, noregistry gives the right mime type, and newregistry is wrong. However, in a few cases, the registry value is right (i.e., according to Apache's mime.types). However, I think that's a totally separate issue, and maybe we should probably open a bug to update a few of the hard-coded mappings in mimetypes.py.

The cases where noregistry is right (according to Apache):

* .aif
* .aifc
* .aiff
* .avi
* .sh
* .wav
* .xsl
*. zip

The cases where noregistry is wrong (according to Apache):

* .bmp is hard-coded as "image/x-ms-bmp", but it should be image/bmp
* .dll and .exe are hard-coded as "application/octet-stream", but should be "application/x-msdownload"
* .ico is hard-coded as "image/vnd.microsoft.icon" but should be "image/x-icon"
* .m3u is hard-coded as "application/vnd.apple.mpegurl" but should be "audio/x-mpegurl"

None of these are standardized IANA mime types, and they're not particularly common for web servers to be serving, so it probably doesn't matter too much that the current hard-coded values are wrong. Also, I'm guessing web browsers will interpret the older type image/x-ms-bmp as image/bmp anyway. So maybe we should open another issue to fix the hard-coded types in mimetypes.py shown above, but again, that's another issue.

The other thing here is all the *new types* that the registry adds, such as ".acrobatsecuritysettings". I don't see that these add much value -- just a bunch of types that depend on the programs you have installed. And in my mind at least, the behaviour of mimetypes.guess_type() should not change based on what programs you have installed.

In short, "noregistry" gives more accurate results in most cases that matter, and I still strongly feel we should revert to that. (The only alternative, in my opinion, is to switch to Dave Chambers' version of read_windows_registry(), but not call it by default.)

----------
Added file: http://bugs.python.org/file29913/different.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________


More information about the Python-bugs-list mailing list