164996 - doesn't recognize pdf attachments in messages from outlook web-access exchange server

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Stephen Martin]

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.

Comment 1

[anthonyd]

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.

Comment 2

[Peter Lubczynski]

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.

Comment 3

[Stephen Martin]

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

Comment 4

[Stephen Martin]

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.    

Comment 5

[anthonyd]

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.

Comment 6

[anthonyd]

im gonna go ahead and take this.

Comment 7

[anthonyd]

confirming this bug.

Comment 8

[Kevin Buhr]

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.

Comment 9

[rubydoo123]

Yes, the server is feeding the wrong mime type, marking as a dupe

*** This bug has been marked as a duplicate of 67940 ***

Comment 10

[anthonyd]

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.

Comment 11

[anthonyd]

fix checked in by peter.

Comment 12

[Kevin Buhr]

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?

Comment 13

[anthonyd]

its [e-mail]

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

Comment 14

[Kevin Buhr]

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.

Comment 15

[rubydoo123]

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

Comment 16

[anthonyd]

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

Comment 17

[anthonyd]

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

Comment 18

[Peter Lubczynski]

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.

Comment 19

[Peter Lubczynski]

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.

Comment 20

[(mostly gone) XtC4UaLL [:xtc4uall]]

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 ?

Comment 21

[(mostly gone) XtC4UaLL [:xtc4uall]]

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

Comment 22

[OstGote!]

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.