Outlook web access attachments download as .aspx

VERIFIED FIXED in Firefox 9

Status

()

Core
General
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Cww, Assigned: Julian Reschke)

Tracking

(Blocks: 1 bug, {dev-doc-complete, regression, verified-beta})

8 Branch
mozilla11
dev-doc-complete, regression, verified-beta
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox9+ verified, firefox10+ verified)

Details

(Whiteboard: [qa!])

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
Seems to be a new problem in Firefox 8:

Copied from support threads:

Why do all my Outlook email attachments now download as "attachment.ashx" (never happened before the 8.0 update)?

After updating Firefox to 8.0, the attachments that come in my Outlook email will not download properly. The file attachment in the email is still correct, but when I go to open or download the file, the window that pops up to ask what to do with the file calls the file "attachment.ashx". I've never seen this before. If I rename the file after downloading, and put the correct format back on it (e.g. .jpg, .pdf), the file opens fine.

How can I get my attachments to download again with their proper file name and file extension? 

https://support.mozilla.com/en-US/questions/895316

===

Suddently yesterday all file types are downloaded as "attachment.ashx" instead of pdf or doc or whatever.

I've been using Firefox for many months to access my work email using Outlook Web Access (OWA). Clicking on an attachment always resulted in the file being downloaded intact (mostly pdfs and Word docs). Suddenly yesterday all file types result in the download of "attachment.ashx". I had not changed anything in Firefox. I restarted Ff and then my computer without effect. I then deleted and reinstalled Ff -- no change. Now in the applications window pdfs and docs aren't listed, but I can't get them in there anyway because they don't download as such. I am using Ff 8.0 on MacOS 10.6.8. 

https://support.mozilla.com/en-US/questions/895024
Adding people who have touched this space recently.
Keywords: regression, regressionwindow-wanted
(Assignee)

Comment 2

6 years ago
This is a known bug in Outlook Web Access, fixed in version 14.1.

See Bug 651185, in particular https://bugzilla.mozilla.org/show_bug.cgi?id=651185#c4 (so FF was the only browser accepting this broken header; Chrome had the same bug reports but WONTFIXed it; see https://code.google.com/p/chromium/issues/detail?id=41308).
(Reporter)

Comment 3

6 years ago
I talked to tech support at Microsoft and they don't know what "version 14.1" means and which actual product it correlates to.  I've asked kev to find out as well as find out what percentage of Exchange servers are update to or past that version.
(Assignee)

Comment 4

6 years ago
(In reply to [:Cww] from comment #3)
> I talked to tech support at Microsoft and they don't know what "version
> 14.1" means and which actual product it correlates to.  I've asked kev to
> find out as well as find out what percentage of Exchange servers are update
> to or past that version.

See <https://code.google.com/p/chromium/issues/detail?id=41308#c35>:

"I can confirm they have "fixed" this issue in Exchange Server 2010 SP1 (X-OWA-Version 14.1.x.x). With SP1 installed, it'd only send the non-standard header to Firefox."

Re-reading this this might say that Microsoft only fixed it for Chrome, but not for FF (which would be very bad).
Not "might"; it _does_ say that.  <sigh>.  Sounds like we need to get Microsoft to fix this...  I'll see if I can get hold of them.

Comment 6

6 years ago
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

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

Comment 7

6 years ago
(In reply to Dimas from comment #6)
> 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
> 
> Uninstalling FF 8 and installing Firefox 7 to the enterprise domain (+- 2000
> PCs) until we have a solution :(

Could you please capture the HTTP response for the download link and post the contents of

  Content-Disposition

and

  X-OWA-Version

?

Comment 8

6 years ago
With FF 8
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
Content-Disposition: attachment; filename*="Formulari%20UDEN-TG.xls"
X-OWA-Version: 14.1.339.1

With FF 7
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Content-Disposition: attachment; filename*="Formulari%20UDEN-TG.xls"
X-OWA-Version: 14.1.339.1

I attach the two headers

Comment 9

6 years ago
Created attachment 575424 [details]
Haders capture with "FF8" and "FF8 with UA of FF7"
(Assignee)

Comment 10

6 years ago
(In reply to Dimas from comment #9)
> Created attachment 575424 [details]
> Haders capture with "FF8" and "FF8 with UA of FF7"

OK, thanks a lot. That conforms that Exchange 2010 SP1 (which I believe reports X-OWA-Version: 14.1.339.1) has the problem (it sends different headers to Firefox and Chrome).

Updated

6 years ago
tracking-firefox10: --- → +
tracking-firefox9: --- → +
(Assignee)

Comment 11

6 years ago
Created attachment 575621 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for beta-src)
Attachment #575621 - Flags: review?(bzbarsky)
(Assignee)

Updated

6 years ago
Hardware: x86 → All
(Assignee)

Comment 12

6 years ago
Created attachment 575622 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for aurora-src)
Attachment #575622 - Flags: review?(bzbarsky)
(Assignee)

Updated

6 years ago
Attachment #575621 - Attachment description: revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for src-beta)) → revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for beta-src)
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Comment on attachment 575621 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for beta-src)

r=me
Attachment #575621 - Flags: review?(bzbarsky) → review+
Comment on attachment 575622 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for aurora-src)

r=me
Attachment #575622 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 15

6 years ago
Comment on attachment 575621 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for beta-src)

Backs out the change for bug 651185, which was a conformance improvement (rejecting a certain syntax that is invalid, and that is rejected by other UAs as well; it turned out that popular servers send different notations based on the User-Agent string, and that it also affected the mail client).
Attachment #575621 - Flags: approval-mozilla-beta?
(Assignee)

Comment 16

6 years ago
Comment on attachment 575622 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for aurora-src)

Backs out the change for bug 651185, which was a conformance improvement (rejecting a certain syntax that is invalid, and that is rejected by other UAs as well; it turned out that popular servers send different notations based on the User-Agent string, and that it also affected the mail client).
Attachment #575622 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 17

6 years ago
Created attachment 575646 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for mozilla-central)

(this is the same patch as for aurora)
Attachment #575646 - Flags: review?(bzbarsky)
Comment on attachment 575646 [details] [diff] [review]
revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for mozilla-central)

r=me
Attachment #575646 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

6 years ago
Attachment #575646 - Flags: checkin?
In my queue with a few other bits that are being sent to try first and then onto inbound :-)

https://tbpl.mozilla.org/?tree=Try&rev=eb96679e6888
Assignee: nobody → julian.reschke
Status: NEW → ASSIGNED
Whoops, appears was missed out from that try run, so I've pushed with some other bits:
https://tbpl.mozilla.org/?tree=Try&rev=4cd7515dd01b

(I know it's only a backout, but can't hurt to send to try on the weekend when infra load is low, given that it's been 4 months since it landed :-) )
https://hg.mozilla.org/integration/mozilla-inbound/rev/06ce4a08992e
Flags: in-testsuite+
Keywords: regressionwindow-wanted
Target Milestone: --- → mozilla11
Attachment #575646 - Flags: checkin? → checkin+

Comment 22

6 years ago
I'm not familiar with BZ flags. Seeing the last movements here maybe will we have a solution for 8.0.x?
(Assignee)

Comment 23

6 years ago
(In reply to Dimas from comment #22)
> I'm not familiar with BZ flags. Seeing the last movements here maybe will we
> have a solution for 8.0.x?

The change is being backed out in the Nightly builds soon. Patches are also available for 9.* and 10.*, and my understanding is the people responsible for these streams will discuss them. Dunno about 8.*.
(In reply to Dimas from comment #22)
> I'm not familiar with BZ flags. Seeing the last movements here maybe will we
> have a solution for 8.0.x?

This does not meet the criteria for an 8.0.1 chemspill build, but we are strongly considering for inclusion in 9 and 10.
https://hg.mozilla.org/mozilla-central/rev/06ce4a08992e
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 26

6 years ago
A previous bug had been opened about this issue, you can close it too.
See Bug 699901

Updated

6 years ago
Duplicate of this bug: 699901

Updated

6 years ago
Blocks: 651185
Keywords: dev-doc-needed

Updated

6 years ago
Attachment #575621 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Updated

6 years ago
Attachment #575622 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Updated

6 years ago
Attachment #575622 - Flags: checkin?
(Assignee)

Updated

6 years ago
Attachment #575621 - Flags: checkin?
https://hg.mozilla.org/releases/mozilla-aurora/rev/de686d1369cd
https://hg.mozilla.org/releases/mozilla-beta/rev/687b18a8709e
status-firefox10: --- → fixed
status-firefox9: --- → fixed
Attachment #575621 - Flags: checkin? → checkin+
Attachment #575622 - Flags: checkin? → checkin+

Comment 29

6 years ago
It's not working for me with with the current nightly (2011-11-23),

About:buildconfig says

Built from http://hg.mozilla.org/mozilla-central/rev/3c8147998124

Tried with a fresh profile
(Assignee)

Comment 30

6 years ago
Can you try the test at 

  http://greenbytes.de/tech/tc2231/#attwithfn2231quot

?

Also, an HTTP header dump from the case *you* tried would be good...

Comment 31

6 years ago
Running the test with the current Nightly, I'm asked to download a file name "foo-ä.html" (this should mean the test is passed, right?)

Here are the headers for an OWA attachment download request:


Request Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-us,en;q=0.5
Connection:keep-alive
Host:owas.reply.it
Referer:https://owas.reply.it/owa/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111123 Firefox/11.0a1

Response Headers

Cache-Control:private
Content-Disposition:attachment; filename*="Manuale%20installazione%20aggiornamento%20ORACOLO_BATCH%20V1.0.docx"
Content-Length:99419
Content-Type:application/vnd.openxmlformats-officedocument.wordprocessingml.document; authoritative=true;
Date:Wed, 23 Nov 2011 21:13:48 GMT
Expires:Tue, 22 Nov 2011 21:13:48 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:2.0.50727
X-OWA-Version:14.1.355.2
X-Powered-By:ASP.NET
X-UA-Compatible:IE=EmulateIE7
(Assignee)

Comment 32

6 years ago
(In reply to Andrea from comment #31)
> Running the test with the current Nightly, I'm asked to download a file name
> "foo-ä.html" (this should mean the test is passed, right?)

Yes.

> Here are the headers for an OWA attachment download request:
> 
> 
> Request Headers
> 
> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Encoding:gzip, deflate
> Accept-Language:en-us,en;q=0.5
> Connection:keep-alive
> Host:owas.reply.it
> Referer:https://owas.reply.it/owa/
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111123
> Firefox/11.0a1
> 
> Response Headers
> 
> Cache-Control:private
> Content-Disposition:attachment;
> filename*="Manuale%20installazione%20aggiornamento%20ORACOLO_BATCH%20V1.0.
> docx"
> Content-Length:99419
> Content-Type:application/vnd.openxmlformats-officedocument.wordprocessingml.
> document; authoritative=true;
> Date:Wed, 23 Nov 2011 21:13:48 GMT
> Expires:Tue, 22 Nov 2011 21:13:48 GMT
> Server:Microsoft-IIS/7.5
> X-AspNet-Version:2.0.50727
> X-OWA-Version:14.1.355.2
> X-Powered-By:ASP.NET
> X-UA-Compatible:IE=EmulateIE7

OMG. Thanks for pointing this out. This means that OWA is even worse than I thought, and FF9+ has additional conformance improvements that will break OWA *again*.
(Assignee)

Comment 33

6 years ago
(In reply to Julian Reschke from comment #32)
> ...
> OMG. Thanks for pointing this out. This means that OWA is even worse than I
> thought, and FF9+ has additional conformance improvements that will break
> OWA *again*.

See bug 704989.
Duplicate of this bug: 705382
Whiteboard: [qa+]

Comment 35

6 years ago
Hey guys,

Could you spell out what you mean when you say "This means that OWA is even worse than I thought".. What part of the response header elicited that comment? Maybe we can get a rfc compliant checkin for E15.

From the bug report above, it looks like you're backing out on the rfc compliance fix for FF8. What build are we doing this in, and how quickly is this build going to be out there for folks to download?

Thanks,
Mohit (Exchange Dev).
Mohit, for the first part, the problem is the the filename*= form of header encoding requires single quotes per the RFC.  So to be compliant you'd want to send something like:

Content-Disposition:attachment; filename*='Manuale%20installazione%20aggiornamento%20ORACOLO_BATCH%20V1.0.docx'

This bug was about backing out the code change that stopped treating double quotes as single quotes.  Bug 704989 backed out the code change that started requiring single quotes.

The change in this bug will appear in Firefox 9, which will be pushed out as an update to Firefox 8 users in 18 days.  If you just want to test a build with the change, you can get a Firefox 9 beta right now, and it should have the changes.

Comment 37

6 years ago
According to my reading of rfc2231, this should read either as

filename*=utf-8''foo%20bar.docx

or even

filename="foo bar.docx" since it's only ascii.

even quoted-string is shown in the examples to be with double quotes.
Could you point me to the spec you are referring to please?

I've tested the format filename*=utf-8''foo%20bar.docx with Firefox 8 and it seems to work fine.

I might be missing something: Could you refer me to the rfc which validates filename*='foo%20bar.docx' please?
Thanks.

Comment 38

6 years ago
Also, are you planning on backing out your changes from any verison of firefox 8?
> filename*=utf-8''foo%20bar.docx

Er, yes.  That's what I meant to write, and somehow failed...

> Also, are you planning on backing out your changes from any verison of firefox 8?

The next planned update to Firefox 8 is Firefox 9.  Again, in 18 days.

Comment 40

6 years ago
Sounds good. Thanks for your help clarifying the situation. While I can't commit to anything, let's wait and see. :-)
(Assignee)

Comment 41

6 years ago
(In reply to Mohit Datta from comment #35)
> Hey guys,

Hi Mohit, thanks for showing up here.
 
> Could you spell out what you mean when you say "This means that OWA is even
> worse than I thought".. What part of the response header elicited that
> comment? Maybe we can get a rfc compliant checkin for E15.

For some time I thought that the only OWA problem was adding double quotes where none were allowed. Only later I realized it also doesn't send the first two components needed in 2231/5987 encoding (charset and language).

For the record, the relevant specs are RFC 6266 (Content-Disposition in HTTP) and RFC 5987 (which defines the "param*" encoding format). Please also visit <http://greenbytes.de/tech/tc2231/>.

(In reply to Boris Zbarsky (:bz) from comment #36)
> Mohit, for the first part, the problem is the the filename*= form of header
> encoding requires single quotes per the RFC.  So to be compliant you'd want
> to send something like:

s/single quotes/no quotes/

> Content-Disposition:attachment;
> filename*='Manuale%20installazione%20aggiornamento%20ORACOLO_BATCH%20V1.0.
> docx'

filename*=UTF-8''Manuale%20installazione%20aggiornamento%20ORACOLO_BATCH%20V1.0.
docx

Note that the parameter value syntax is defined as "ext-value" in <http://greenbytes.de/tech/webdav/rfc5987.html#rfc.section.3.2.1>

> This bug was about backing out the code change that stopped treating double
> quotes as single quotes.  Bug 704989 backed out the code change that started
> requiring single quotes.

This bug was about stopping to accept double quotes. Other related bugs we have backed out were about requiring the single quote delimiters (ext-value) being there, and requiring the presence of the charset.

> The change in this bug will appear in Firefox 9, which will be pushed out as
> an update to Firefox 8 users in 18 days.  If you just want to test a build
> with the change, you can get a Firefox 9 beta right now, and it should have
> the changes.

But, by any means, for testing OWA, please test with FF8. It behaves exactly as it should (and, the same way as Chrome and IE, for instance). The important thing is to get rid of most of the UA sniffing. All UAs except Safari and IE-pre-9 accept the same syntax.


(In reply to Mohit Datta from comment #37)
> According to my reading of rfc2231, this should read either as

...yes, but you really should look at RFC 5987.
 
> filename*=utf-8''foo%20bar.docx
> 
> or even
> 
> filename="foo bar.docx" since it's only ascii.

Right.

> even quoted-string is shown in the examples to be with double quotes.
> Could you point me to the spec you are referring to please?
> 
> I've tested the format filename*=utf-8''foo%20bar.docx with Firefox 8 and it
> seems to work fine.

Of course it does :-)

> I might be missing something: Could you refer me to the rfc which validates
> filename*='foo%20bar.docx' please?

There are none; Boris apparently got confused with various different changes made at the same time.

(In reply to Mohit Datta from comment #40)
> Sounds good. Thanks for your help clarifying the situation. While I can't
> commit to anything, let's wait and see. :-)

Again, thanks for the feedback. Can we state that Microsoft is now aware of the problem, has analyzed it, and treats it as issue internally?
Has someone taken the action to fix the RFC to allow double quotes? It sucks to have breakage like this because the spec doesn't reflect the real world.
(Assignee)

Comment 43

6 years ago
(In reply to Henri Sivonen (:hsivonen) from comment #42)
> Has someone taken the action to fix the RFC to allow double quotes? It sucks
> to have breakage like this because the spec doesn't reflect the real world.

The (revised) RFC is relatively new. The issue wasn't brought up when it was discussed.

I'm working on another revision right now (<http://tools.ietf.org/html/draft-reschke-rfc5987bis>).

My test cases show that of the browsers, *only* Firefox allows double quotes, so changing this would make all the others non-compliant (<http://greenbytes.de/tech/tc2231/#attwithfn2231quot> and <http://greenbytes.de/tech/tc2231/#attwithfn2231quot2>).

Furthermore, the problem of OWA is not only adding double quotes, but also not sending other required fields elements (at least the delimiters for charset and language). Essentially it wraps what happens to "work" for IE into something which "works" in FF < 8, but no other UA.

Comment 44

6 years ago
Look at the last post of Microsoft (Dmitry Alexeenko [MSFT]) here: http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/0e91199f-bb00-469c-a20e-0a302d2197ce/

"Thank you for reporting the issue. Firefox 8 has a change that enforces some parts of RFC 2231 (https://developer.mozilla.org/en/Firefox_8_for_developers#Network) - in particular it no longer accepts double quotes as delimiters within MIME parameters.

Unfortunately, this change broke Outlook Web App. We are aware of this issue and are working on the fix.

If you would like to track the status of the issue, please contact Microsoft support."

Comment 45

6 years ago
I have tried this using the steps from the description with Outlook Web Access.
The files attached were a test pdf and an html file.

Both files are downloaded as pdf and html:
Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6
Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6

Setting resolution to Verified Fixed on Beta
Keywords: verified-beta
Whiteboard: [qa+] → [qa+][qa!:9]

Comment 46

6 years ago
(In reply to Vlad [QA] from comment #45)
> I have tried this using the steps from the description with Outlook Web
> Access.
> The files attached were a test pdf and an html file.
> 
> Both files are downloaded as pdf and html:
> Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6
> Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101
> Firefox/9.0 beta 6
> 
> Setting resolution to Verified Fixed on Beta

Just to clarify, can I tell users (like this https://support.mozilla.com/en-US/questions/895316 and https://support.mozilla.com/en-US/questions/897957 ) that they should download Fx 9 because their attachments will download correctly now?
(Assignee)

Comment 47

6 years ago
(In reply to Verdi from comment #46)
> Just to clarify, can I tell users (like this
> https://support.mozilla.com/en-US/questions/895316 and
> https://support.mozilla.com/en-US/questions/897957 ) that they should
> download Fx 9 because their attachments will download correctly now?

They did before, just not with the intended name. This should work now again.

In any case, anybody affected by this should bug Microsoft for a fix in OWA...

Updated

6 years ago
status-firefox9: fixed → verified

Comment 48

6 years ago
I have verified this using the steps from the description on:
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2
Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 2

Both files are downloaded as expected. See comment45.
Status: RESOLVED → VERIFIED
status-firefox10: fixed → verified
Whiteboard: [qa+][qa!:9] → [qa!]

Updated

5 years ago
Blocks: 717874
Mentioned on Firefox 11 for developers.
Keywords: dev-doc-needed → dev-doc-complete

Comment 50

5 years ago
I am experiencing the problem with Firefox 12.0 and OWA 14.1.355.2 since the update from the previous stable channel release. The file name is rubbish. The <extension> is fine however, .pdf for example.

The individual attachment files are named bttachment.<extension>

Comment 51

5 years ago
Filed Bug 754796 with some more details to reported issue since this one here is closed.
You need to log in before you can comment on or make changes to this bug.