After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 422871 - evolution fails to offer "open" attachments for upper-case MIME types
evolution fails to offer "open" attachments for upper-case MIME types
Status: RESOLVED DUPLICATE of bug 523271
Product: evolution
Classification: Applications
Component: Mailer
2.10.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Ashish
Evolution QA team
evolution[attachments]
: 447287 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-26 03:09 UTC by Mark Stosberg
Modified: 2009-03-27 21:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Mark Stosberg 2007-03-26 03:09:01 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:
Comment 1 André Klapper 2007-06-14 13:26:45 UTC
*** Bug 447287 has been marked as a duplicate of this bug. ***
Comment 2 Ashish 2007-08-14 09:07:32 UTC
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.

Comment 3 Ashish 2007-08-18 10:44:20 UTC
I have checked with Evo 2.8.2 also. I don't get it at all.
Comment 4 Mark Stosberg 2007-08-18 13:27:57 UTC
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
Comment 5 Ashish 2007-08-20 09:42:16 UTC
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
Comment 6 C de-Avillez 2008-03-25 20:28:18 UTC
this seems the same as bug 523271. mbarnes has proposed a patch for it there.
Comment 7 Matthew Barnes 2009-03-27 21:57:14 UTC
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 ***