703015 - Outlook web access attachments download as .aspx

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[[:Cww]]

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

Comment 1

[Christopher Blizzard (:blizzard)]

Adding people who have touched this space recently.

Comment 2

[Julian Reschke]

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).

Comment 3

[[:Cww]]

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.

Comment 4

[Julian Reschke]

(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).

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

[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

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

Comment 7

[Julian Reschke]

(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

[Dimas]

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

[Dimas]

Attachment: Haders capture with "FF8" and "FF8 with UA of FF7"

Comment 10

[Julian Reschke]

(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).

Comment 11

[Julian Reschke]

Attachment: revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for beta-src)

Comment 12

[Julian Reschke]

Attachment: revert change for bug 651185 - allow double-quotes for RFC 2231/5987 encoding again (for aurora-src)

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Julian Reschke]

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).

Comment 16

[Julian Reschke]

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).

Comment 17

[Julian Reschke]

Attachment: 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)

Comment 18

[Boris Zbarsky [: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

Comment 19

[Ed Morley [:emorley]]

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

Comment 20

[Ed Morley [:emorley]]

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 :-) )

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/06ce4a08992e

Comment 22

[Dimas]

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

Comment 23

[Julian Reschke]

(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.*.

Comment 24

[Alex Keybl [:akeybl]]

(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.

Comment 25

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/06ce4a08992e

Comment 26

[Loic]

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

Comment 28

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/de686d1369cd
https://hg.mozilla.org/releases/mozilla-beta/rev/687b18a8709e

Comment 29

[Andrea]

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

Comment 30

[Julian Reschke]

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

[Andrea]

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

Comment 32

[Julian Reschke]

(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*.

Comment 33

[Julian Reschke]

(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.

Comment 35

[Mohit Datta]

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).

Comment 36

[Boris Zbarsky [:bzbarsky]]

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

[Mohit Datta]

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

[Mohit Datta]

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

Comment 39

[Boris Zbarsky [:bzbarsky]]

> 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

[Mohit Datta]

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

Comment 41

[Julian Reschke]

(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?

Comment 42

[Henri Sivonen (:hsivonen)]

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.

Comment 43

[Julian Reschke]

(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

[Dimas]

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

[Vlad [QA]]

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

Comment 46

[Verdi [:verdi] Best to slack me]

(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?

Comment 47

[Julian Reschke]

(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...

Comment 48

[Vlad [QA]]

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.

Comment 49

[Eric Shepherd [:sheppy]]

Mentioned on Firefox 11 for developers.

Comment 50

[Sven Ludwig]

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

[Sven Ludwig]

Filed Bug 754796 with some more details to reported issue since this one here is closed.