The mime-type image/bmp has been declared to also have the alias image/x-MS-bmp. It seems this is not recognized when servers send a file with type image/x-ms-bmp (in all lower case). Are not all mime-types in the database supposed to be lower-case? I am guessing the upper-case is either a mistake, or the another alias with lower-case is needed.
See http://bugs.kde.org/show_bug.cgi?id=273238 for an example.
Created attachment 72620 [details] [review] Patch Lower case the mimetype like all other mimetypes in the database.
As per http://tools.ietf.org/html/rfc2045#section-5.1 : "The type, subtype, and parameter names are not case sensitive." Which means that image/x-MS-bmp and image/x-ms-bmp are the same mime-type. I've added a test case to shared-mime-info, and updated the test applications in xdgmime to match this. It's possible that xdgmime's reference implementation will fail in some cases though. I'm not certain requesting the glob for audio/amr would return the correct answer for example.
I'll close this, feel free to file a new bug against xdgmime if there's a particular problem with the reference implementation.
Isn't problem that code might depend on the mime-types in the database to be lower case exactly because they are case insensitive, and there is no reason to store them with case?
(In reply to comment #5) > Isn't problem that code might depend on the mime-types in the database to be > lower case exactly because they are case insensitive, and there is no reason > to store them with case? From a documentation and interoperability point-of-view, I don't see how we can stop web servers from sending image/x-MS-bmp instead of image/x-ms-bmp. If you don't do a case insensitive string comparison, you've already lost.
(In reply to comment #6) > (In reply to comment #5) > > Isn't problem that code might depend on the mime-types in the database to be > > lower case exactly because they are case insensitive, and there is no reason > > to store them with case? > > From a documentation and interoperability point-of-view, I don't see how we > can stop web servers from sending image/x-MS-bmp instead of image/x-ms-bmp. > If you don't do a case insensitive string comparison, you've already lost. The problem was not that the web servers is sending image/x-MS-bmp, it was actually sending image/x-ms-bmp. It was that the database that contains image/x-MS-bmp, when all other mimetypes in the database are lowercase. This breaks case insensitive comparisons made by lower casing the external mimetype. Sure we could do full case insensitve comparison, but it still seems this entry breaks a common pattern and entry style in the database.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Isn't problem that code might depend on the mime-types in the database to be > > > lower case exactly because they are case insensitive, and there is no reason > > > to store them with case? > > > > From a documentation and interoperability point-of-view, I don't see how we > > can stop web servers from sending image/x-MS-bmp instead of image/x-ms-bmp. > > If you don't do a case insensitive string comparison, you've already lost. > > The problem was not that the web servers is sending image/x-MS-bmp, it was > actually sending image/x-ms-bmp. Same difference. Both are correct, and KDE should be handling both of them the same way. It should also be handling Image/x-ms-bmp IMage/x-ms-bmp, IMAge/x-ms-bmp, etc. the same way. > It was that the database that contains > image/x-MS-bmp, when all other mimetypes in the database are lowercase. You're clutching at straws. The fact that (nearly) everything happened to be lower-case in the database was just papering over the fact that some of the implementation might be broken. > This > breaks case insensitive comparisons made by lower casing the external > mimetype. If you're already lower-casing the mime-type from one side, why can't you lower-case it from both sides? Or simply do a case insensitive comparison? > Sure we could do full case insensitve comparison, but it still > seems this entry breaks a common pattern and entry style in the database. The mime-type got added (in bug 16410) from the same definition in gdk-pixbuf. I see no reason to change it (and adding more duplicate aliases won't fix it).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.