Hello Everyone,

This has been quite exhausting, but I think I may have found the answer to this question. Sadly enough, I'm not sure the fix can be applied by Mozilla or Us (maybe through a special plugin or something like that).

It seems, through all my research and investigation today that this problem stems from the "Content-Disposition" header that is sent from OWA. If you look at my earlier screenshot, you will notice this line:

Content-Disposition: attachment; filename*="CNF%20#1.xls"

This notation using *= comes from the RFC 2231 Standard and shows that the above is actually incorrect. This header should be sent to the browser like this:

Content-Disposition: attachment; filename*=''CNF%20#1.xls

In the above notation, please note that '' are two single quotes side by side. The reason for this notation is described in the following excerpt from page 4 of the RFC 2231 Standard.

*** START QUOTE ***

Asterisks ("*") are reused to provide the indicator that language and
character set information is present and encoding is being used. A
single quote ("'") is used to delimit the character set and language
information at the beginning of the parameter value. Percent signs
("%") are used as the encoding flag, which agrees with RFC 2047.

Specifically, an asterisk at the end of a parameter name acts as an
indicator that character set and language information may appear at
the beginning of the parameter value. A single quote is used to
separate the character set, language, and actual value information in
the parameter value string, and an percent sign is used to flag
octets encoded in hexadecimal. For example:

Content-Type: application/x-stuff;
title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

Note that it is perfectly permissible to leave either the character
set or language field blank. Note also that the single quote
delimiters MUST be present even when one of the field values is
omitted. This is done when either character set, language, or both
are not relevant to the parameter value at hand. This MUST NOT be
done in order to indicate a default character set or language --
parameter field definitions MUST NOT assign a default character set
or language.

*** END QUOTE ***

I have been successful in re-creating the problem using PHP to send the same incorrect header as above. When downloading the file it downloaded as attachment.php. I then solved the problem by using my corrected Content-Disposition header and VOILA, problem solved, I was now being served the download with the correct file name and extension.

This would explain attachment.ashx since this is the file that serves your attachments as a download. This is where the Content-Disposition header needs to be changed. I currently have my IT team looking into this to find out if we have access to the code to make the necessary fixes to make these downloads work properly again. I will post when I get more information from them.

I can't find the post right now, but I read somewhere that Mozilla has fixed the way Content-Disposition is read, and it now conforms to the RFC 2231 Standard. This means that this is not a bug in Firefox, but a bug in OWA.

I would like to thank cor-el for indirectly pointing me in the right direction. If he hadn't drawn my attention to the Content-Type, I never would have noticed the malformed Content-Disposition header.

One last thing, I also tested the above in IE9 and you'll never guess what... IE9 doesn't even support this notation at all. IE9 accepts the following:

Content-Disposition: attachment; filename=CNF%20%231.xls

Note that I also had to encode the #... Hmmm...

Well, that's all. I hope this has helped someone or at least maybe saved some hair pulling ;-)

Cheers,
titanicfanatic

References

http://dev.simplemachines.org/mantis/view.php?id=4825

This post lead me to this one which gave me the answer ;-)

http://www.simplemachines.org/community/index.php?topic=451766.0

There have been 8062 visits to this page!