User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 The .pdf plug-in doesn't seem to recognize .pdf files when they are attachments in an email message accessed through Outlook Web-Access connected to an Exchange server. When a .pdf attachment is double-clicked, the browser prompts the user to save the file to disk as an .exe rather than opening it. This does not happen if: 1) The email is downloaded using messenger. 2) There is a link to the .pdf on an ordinary web page. Reproducible: Always Steps to Reproduce: 1. Mail a .pdf file as an attachment to an account on a server running Microsoft Exchange Server 2. Access the account using Outlook Web-Access 3. Double-click the attachment. Actual Results: A blank browser window opens briefly before the browser prompts the user to save the file to disk as an .exe. The .pdf file is then saved as somefilename.pdf.exe and can not be opened. Expected Results: Either the .pdf should open in a new browser window or Adobe Acrobat Reader should be launched and display the file. This happens on every computer in the office I have Mozilla installed on. These run the gamut from P2 to p4's, and running both NT4 and XP. This was true for both Mozilla 1.0 and 1.1.

I don't see how this is our issue at all. I can open pdf files in mozilla and netscape when they are sent and read through our respective client. Unless a more compelling case can be demonstrated as to how mozilla has caused this problem, then I am marking this INVALID.

Anyone have access to a test account on an Exchange server that can be used to verify this bug? It sounds like the HTTP header has the wrong mime type and we are not looking at the extension.

*** Bug 165029 has been marked as a duplicate of this bug. ***

Yes, by all means verify it through the web-access. I realize that this is a pretty specific bug: pdf attachment, exchange server, outlook web-access client, and it seems like it could be exchange doing something "unexpected". Unfortunately, I have no direct control over the email at work (the server is up at corporate) other than trying to wean people off IE on the client side. So, the only real case I can make at this point is that the attachments open up correctly in IE and not in Mozilla. Anyway, I'll get in touch with the people back at corporate and ask them about the mime header and have them check that they don't have something misconfigured.

Re-opening the bug after speaking with peterl. It is entirely possible that this is our bug. We might be following the http spec too closely and not looking at the file extension (like 4.x and IE do). I'm sorry for jumping the gun on this one, but I thought we looked at file extensions with Mozilla. It seemed to me like either header munging by MS or a server setup incorrectly. Will investigate this with Peter.

im gonna go ahead and take this.

confirming this bug.

I can verify that comment #2 is correct here. When Mozilla fetches an attachment, the server replies with a: Content-Type: application/octet-stream header whatever file type the attachment actually is. This is with "Microsoft Outlook Web Access for Microsoft Exchange Server" Version 5.5 SP4, according to its login screen. I know the server version would be of more interest here, but there's no "Server:" header. I can find out, if it's important, but it seems reasonable that Mozilla should do extension matching when a web server serves up a "stupid" MIME type like "octet-stream". Or, there should be a way in the Helper Applications dialogue to say "handle this particular MIME type by doing extension matching instead". Anthony, this should be marked a duplicate of bug 67940 or vice versa.

Yes, the server is feeding the wrong mime type, marking as a dupe *** This bug has been marked as a duplicate of 67940 ***

no the server is not feeding the wrong mime type. what happens is we are folowing the mime type spec too closely and we are ignoring the file extension. There are a few bugs that are open already regarding this, but they all have different test cases. THis is one of the bugs I have been working with peter on. Once I have finished testing peters patch, we should be able to close all of these out if it fixes them.

fix checked in by peter.

Bonsai shows no appropriate checkin by ^peterlub.* within the past week, and I can't see anything relevant in the uriloader module (where I kind of expected the change to take place). Was it checked in on the commercial tree or something? Could we maybe get the patch attached here?

its peterl@netscape.com and here is the link for the checkin: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/docshell/base&command=DIFF_FRAMESET&file=nsDocShell.cpp&rev2=1.476&rev1=1.475

Unfortunately, Peter's patch doesn't fix the original problem: accessing attachments under Microsoft Outlook Web Access. The problem is that the URL for such an attachment (at least for the Outlook Web Access version I'm using) looks like: http://hostname/exchange/Attach/read.asp?obj=<enormous_identifier>-filename.ext where "filename.ext" is the "proper" filename with extension of the attachment. The url->GetFileExtension method grabs the "asp" which isn't much use in identifying the correct type. I see two possible approaches. One is to favour the "Content-Disposition" header's filename extension over the URL's extension. That's the approach I took in a patch for bug 67940, though my particular implementation missed the mark. Another approach is to try to get the "true" extension from the tail end of the URL. The problem there is identifying in what very special cases we should be believing an "extension" in the "?..." component of a URL over the URL's proper extension. I'm going to reopen this bug; I hope I'm not stepping on any toes.

Peter: can you retry your patch based on Kevin's comments in comment #14

argh midair collision! What I was saying was that i will discuss this with peterl a bit more. I also sent an email to the original reporter asking for a bit more clarification on thier bug problem. I also look at the patch in bug 67940 and I do see what he is proposing. It is a good idea, but I dont think it is the plugin area that should handle breaking down the content before/after a .asp or a .cgi extension. The URI loader should handle that and do the *smart thing*. ADavis

A possible idea would be to modify the patch peter checked in to something like GetRawFileName instead of GetFileExtension and then do our own *thing* by looking backwards for the '.' and parse out our own file extension. The issue with THAT is, where do we stop? Which '.' and '?' do we parse out, and how many? Somone could have something like: http://foo.com/readmy.cgi?readthis.asp?some_plugin.ext obviously that is a bogus example, but it is something I just pulled out of this air. We had this similar problem argument in the 4.x days. ADavis

This bug needs a testcase. I'm now loading up server/excahnge/OWS in a vm but maybe someone can beat me to it... I don't think we should be looking in the query string part of the URL for extensions unless we find it's necessary to be compatible with Nav and IE.

I still havn't been able to setup a W2K Server with Exchange. Access to one of those is necessary for resolving and verifying this bug.

I tried to repro this using my companies Outlook Web Exhange. - the Link to a Mail with an PDF-Attachment is like this: .../$Subject_Of_The_Mail$.EML/$Name_Of_The_Attached_File$.pdf/$A_GUID$/$Name_Of_The_Attached_File$.pdf?attach=1 - I'm not allowed to open (and view) the PDF-File with left-click but am being prompted to right-click an save the file for offline viewing -> INVALID/WORKSFORME ?

i forgot to mention i tested above with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070804 ID:2007070804 and MSIE 7

After 5 years and comment 20 I mark this bug as WFM. Feel free to reopen it if you can provide more data or steps to reproduce it with current builds.