699901 - All Outlook Web App attachments are saved as "attachment.ashx"

Status: RESOLVED DUPLICATE of bug 703015

(Firefox :: General, defect)

Description

[Andrea]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111102223350

Steps to reproduce:

Tried to download an attachment from OWA 2010 with Firefox 8.0 beta by clicking on it and also by right clicking and choosing Save As.


Actual results:

Attachment is always downloaded as "attachment.ashx"


Expected results:

Attachement should preserve its original name when downloaded

Comment 1

[mattosaur4]

I am also experiencing this on FireFox 8.0 for Mac.  10.6.8.  

All PDF attachments from OWA are being downloaded as "attachment.ashx".  

Removing FireFox 8 and going back to 7.0.1 and repeating the same steps downloads an openable PDF with the correct name. 

This seems to be a new problem with version 8.

Comment 2

[Andrea]

To me it happens also with office and zipped files.
Actually, with any file type I've tried to download so far.

Comment 3

[KDS]

Same for both Windows XP SP3 and Mac OS X 10.6.x and 10.7.x

Attachments are saved/opened as "attachment.ashx", even though the system suggests to open with the appropriate application e.g. Excel, Acrobat, etc.

Happens will all attachments.
Both on Windows and Mac OS X.
Changed useragent of Firefox 8.0 to Chrome and problem went away.

Doesn't happen with Internet Explorer, Safari, Chrome or Firefox 7.0.1

Comment 4

[Andrea]

I'm starting to think it's not a Firefox bug, maybe OWA expects a known User Agent String and Firefox 8.0 is too recent?
I found some Chrome users reporting the same problem: it would be interesting to see owa behaves with a development build of other browsers

Comment 5

[mattosaur4]

Can also confirm this happens for me in FireFox 8 release version under Windows 7 64bit.  Doesn't happen in FireFox 7.0.1 on Windows.

Windows is however appending the proper extension onto .ashx. so it's attachment.ashx.pdf  whereas on Mac OS it doesn't. 

Also getting attachment.ashx on Lion 10.7.2 with FireFox 8 and OWA 2010.

Matt

Comment 6

[Loic]

It's reported by many users here: https://support.mozilla.com/fr/questions/894442 (add URL if possible)

This issue was present in Chrome too, see
http://www.google.com/support/forum/p/Chrome/thread?tid=64d96862f913980a&hl=en
and
http://www.google.com/support/forum/p/Chrome/thread?tid=3f75b57feb936449&hl=en

It was a bug in Exchange 2010 and Microsoft released a bugfix, see http://support.microsoft.com/Default.aspx?kbid=976573

So maybe it's again a bug in OWA.

Comment 7

[Aren Cambre]

Similar, but limited to Mac: https://bugzilla.mozilla.org/show_bug.cgi?id=688194

Comment 8

[Loic]

Can someone confirm that changing the user agent in FF8 (by the UA of FF7) is a possible workaround?
There are some add-ons for that, like UA Switcher: https://addons.mozilla.org/fr/firefox/addon/user-agent-switcher/

UA to choose (for Win 7 64bits):
Description : Firefox 7.0.1
User Agent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1

Can someone test with OWA?

Comment 9

[Andrea]

Can't get it working with OWA2010 and the 7.0.1 UA String, but I should mention that I'm now using Fx9 beta

Comment 10

[Dimas]

Tested with FF 8.0, Windows 7 32b and the extension UAControl with UA "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" and it doesn't work with OWA 14.1.339.1

Comment 11

[Dimas]

Uninstalling FF 8 and installing Firefox 7 to the enterprise domain (+- 2000 PCs) until we have a solution :(

Comment 12

[Loic]

The issue needs to be addressed to Microsoft, because I guess the issue is similar to what Chrome met in 2010 with OWA. If the UA whitelist is hardcoded in OWA, Microsoft needs to fix that.

Comment 13

[Dimas]

Maybe Loice, but meanwhile we will have to use Firefox 7

Comment 14

[Dan]

Same issues here, was fine until Firefox 8 so its Firefox 8 causing it.   I updated 200 Macs to the latest version and then someone let us know about it.  Was hoping to see 8.0.1 fix the issue, but it hasn't even been assigned to anyone so doesn't look promising.

Comment 15

[Andrea]

(In reply to Loic from comment #12)
> The issue needs to be addressed to Microsoft, because I guess the issue is
> similar to what Chrome met in 2010 with OWA. If the UA whitelist is
> hardcoded in OWA, Microsoft needs to fix that.

Then how could it be that the UA set with UAControl doesn't pass the hard coded whitelist, being the same as Fx 7?

Comment 16

[Loic]

(In reply to Andrea from comment #15)
> (In reply to Loic from comment #12)
> > The issue needs to be addressed to Microsoft, because I guess the issue is
> > similar to what Chrome met in 2010 with OWA. If the UA whitelist is
> > hardcoded in OWA, Microsoft needs to fix that.
> 
> Then how could it be that the UA set with UAControl doesn't pass the hard
> coded whitelist, being the same as Fx 7?

It worked for some users, see https://support.mozilla.com/fr/questions/894442?page=2
(and can you add this URL in the bug header, please, and maybe change OWA by Outlook Wep App)

I quote some evidences about the bug:
>In terms of proof, have them download the 'Live HTTP Headers' addon for Firefox, >this will sniff out all headers that are being sent to the browser, and it's very >obvious that it's OWA's fault as it doesn't conform to the standard which was >outlined in RFC 2231. You could also maybe have them try a download in IE9 which >you think should have no problem since they are developed by the same company (OWA >and IE9), but with IE9 becoming a more standards compliant browser, even it >doesn't accept this malformed Content-Disposition. Is that really a browser bug, I >think not!

Comment 17

[Loic]

Sorry, bad quote:

In terms of proof, have them download the 'Live HTTP Headers' addon for Firefox,
this will sniff out all headers that are being sent to the browser,
and it's very obvious that it's OWA's fault as it doesn't conform to the standard
which was outlined in RFC 2231. You could also maybe have them try a download in IE9
which you think should have no problem since they are developed by the same company
(OWA and IE9), but with IE9 becoming a more standards compliant browser, even it
doesn't accept this malformed Content-Disposition. Is that really a browser bug, I
think not!

Comment 18

[Dimas]

Loic, it worked ONLY for some users, see https://bugzilla.mozilla.org/show_bug.cgi?id=703015#c8

Comment 19

[mattosaur4]

My User Agent Testing via the User Agent Switcher addon.  Windows 7 32bit, OWA Version: 14.1.339.1

Results in a .ashx file
User-Agent: Mozilla/5.0 ‎(Windows NT 6.1; rv:8.0)‎ Gecko/20100101 Firefox/8.0

Results in a normally named .pdf
User-Agent: Opera/9.80 ‎(Windows NT 6.1; U; en)‎ Presto/2.7.62 Version/11.01
User-Agent: Mozilla/5.0 ‎(Windows; U; Windows NT 6.1; en-US)‎ AppleWebKit/533.19.4 ‎(KHTML, like Gecko)‎ Version/5.0.2 Safari/533.18.5

Mac OS X 10.6.8  - OWA Version: 14.1.339.1

Results in a .ashx file
User-Agent: Mozilla/5.0 ‎(Macintosh; Intel Mac OS X 10.6; rv:8.0)‎ Gecko/20100101 Firefox/8.0
User-Agent: Mozilla/5.0 ‎(Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre)‎ Gecko/20100907 Firefox/4.0b6pre Camino/2.2a1pre
User-Agent: Mozilla/5.0 ‎(Macintosh; Intel Mac OS X 10.6; rv:5.0)‎ Gecko/20100101 Firefox/5.0
User-Agent: Mozilla/5.0 ‎(Macintosh; Intel Mac OS X 10_7_2; rv:10.0.1)‎ Gecko/20100101 Firefox/10.0.1

Then changing to any of the following User Agent's without even restarting the browser results in a normally named .pdf file.

User-Agent: Mozilla/5.0 ‎(Macintosh; Intel Mac OS X 10_6_8)‎ AppleWebKit/535.7 ‎(KHTML, like Gecko)‎ Chrome/16.0.912.36 Safari/535.7
User-Agent: Opera/9.80 ‎(Macintosh; Intel Mac OS X 10.6.8; U; fr)‎ Presto/2.9.168 Version/11.52
User-Agent: Mozilla/5.0 ‎(Macintosh; U; Intel Mac OS X 10_6_6; en-us)‎ AppleWebKit/533.20.25 ‎(KHTML, like Gecko)‎ Version/5.0.4 Safari/533.20.27