[issue10551] mimetypes read from the registry should not overwrite standard mime mappings

[Ben Hoyt]

Ben Hoyt added the comment:

This is definitely a real issue, and makes mimetypes.guess_type() useless out of the box on Windows.

However, I believe the reason it's broken is that the fix for Issue4969 doesn't actually work, and I'm not sure this is possible with the Windows registry.

You see, "MIME\Database\Content Type" in the Windows registry is a mime type -> file extension mapping, *not the other way around*. But read_windows_registry() tries to use it as a file extension -> mime type mapping, and bad things happen, because there are multiple mime types for certain file extensions.

As far as I can tell, there's nothing in the Windows registry that says which is the "canonical" mime type for a given extension. Again, this is because Microsoft intends it (and uses it) as a mime type -> extension mapping. See more here: http://msdn.microsoft.com/en-us/library/ms775148(v=vs.85).aspx

For example, in my "MIME\Database\Content Type" we have:

image/jpeg -> .jpg
image/jpg -> .jpg
image/pjpeg -> .jpg

And read_windows_registry() picks the last one for .jpg, which in this case is image/pjpeg -- NOT what users expect.

In short, I think the fix for Issue4969 is broken as is, and that you can't actually use the mime types database in the Windows registry in this way. I suggest reverting the fix for Issue4969.

Or, we could get clever and only use the Windows registry value if there's a single mime type -> extension mapping for a given extension, and if there's more than one (meaning it'd be ambiguous), use the mimetypes default from types_map / common_types.

----------
nosy: +benhoyt

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