Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2017-12-08.12:51:43.854>created_at=<Date2014-10-09.19:00:16.534>labels= ['easy', 'type-bug', '3.7', 'expert-IO']
title='mimetypes uses image/x-ms-bmp as the type for bmp files'updated_at=<Date2017-12-08.12:51:43.851>user='https://bugs.python.org/brma'
In the file mimetypes.py the mime type for bmp files should be image/bmp for IE8 and later. the problem is that if the content header for 'nosniff' is set, then the bmp file fails to display due to the incorrect mime type.
Using image/x-ms-bmp because that's all that IE7 supports makes no sense. Chrome doesn't support image/x-ms-bmp (it only supports the official IANA type image/bmp), so if the concern is over browser support then it's clear that Chrome (the browser with the most market share) should trump IE7 (a browser that stopped getting support/security updates at the beginning of 2016, and has virtually no browser share).
I should note that while Chrome will refuse to open an image/x-ms-bmp file directly, when loaded as an image embedded in a document (e.g. via HTML's <img>) then Chrome doesn't care what MIME type it has. It will sniff the image stream and detect from its contents that it is a BMP image and correctly render it.
If image/bmp is now[*] the official IANA type, mimetypes should use that. However, because this is a change with possible backward compatibility issues, it should probably only go into 3.7, but I'm open to arguments about that.
[*] The mimetypes module is very old and nobody specifically maintains it; we depend on user reports for updates to it, and obviously this one was overlooked. Care to prepare a PR?
I'm unfamiliar with the Python contribution procedures. If it's simply a case of cloning from github.com and putting up a PR then I can do that. I'm overloaded currently though, so if it's more involved than that it may take me a while to figure things out.
That's the basis, but its a bit more complicated than that (NEWS item, putting bpo-22589 in the issue title, the question of signing a CLA, though a CLA doesn't really matter for this kind of change IMO). If you can't do it one of our core-mentorship volunteers will take care of it, I'm sure.
Thanks, nitishch. As I said, I'm not going to backport this unless someone advances an argument in favor that discusses the possible backward compatibility issue. (I'm not sure there are any significant ones, but someone needs to research it and present the results.)