GNOME Bugzilla – Bug 422871
evolution fails to offer "open" attachments for upper-case MIME types
Last modified: 2009-03-27 21:57:14 UTC
Please describe the problem: I'm using Evo 2.8.0. I got a "WAV" attachment, and there was no option to open it directly, like Thunderbird offered. This is due to a bug in this version of Evo, which does not follow the MIME standard that mime-types should be case-insensitive. The attachment I got had a MIME type of "audio/x-WAV". Evo should have recognized that this was the same as "audio/x-wav", but it did not. ( For reference: http://www.faqs.org/rfcs/rfc2045.html "Matching of media type and subtype is ALWAYS case-insensitive" ) The workaround, at least on Mandriva Linux 2007, was to edit /usr/share/applications/defaults.list I found that line that said: audio/x-wav=totem.desktop I added another line below it: audio/x-WAV=totem.desktop Then (after perhaps a restart of Evo), it offered me the option to open the wav file with Totem, as I wanted. I searched the bug database to see if this might have been fixed in a newer version, but I found no record that it was. Mark Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
*** Bug 447287 has been marked as a duplicate of this bug. ***
Mark, I didn't find any issue with to "open" attachments for upper-case MIME types. I have verified with Evolution version-2.11.6.1. I'm followed the same scenario, which mentioned above in bug summary. For to open a WAV file as an attachment, I found that option to opening a Wav file, i.e "msg0002.WAV" , as "Open in real player..", "Open in Noatun", "Open in Totem" etc. and able to play file also. I haven't tested with that with Evo 2.8.0. I will do that and get back.
I have checked with Evo 2.8.2 also. I don't get it at all.
Hello, Thank you for looking into this bug. I don't think it's related to the case of the extension, but of the MIME type embedded in the e-mail, visible with "view source". Mark
Hi, Right, It's not related to the case of extension.I am trying to find a cause of issue. I'll get back to you. As per my knowledge, the top-level media type(here is "audio") is used to declare the general type of data, while the subtype(here is "wav") specifies a specific format for that type of data. Thus, a media type of "audio/x-WAV” is enough to tell a user agent that the data is an audio, even if the user agent has no knowledge of the specific audio file format "wav". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype. As such do not fundamentally affect the nature of the content. The type and subtype names are not case sensitive. Ashish
this seems the same as bug 523271. mbarnes has proposed a patch for it there.
Yeah, this is a dupe of bug #523271. gnome-vfs (now GIO) expected lowercase MIME types and so it would fail to match something like audio/x-WAV against its MIME database. We now explicit covert MIME types to lowercase before doing the lookup. *** This bug has been marked as a duplicate of 523271 ***