160886 - Save As dialog doesn't honor Content-disposition filename extension

Status: VERIFIED DUPLICATE of bug 120327

(Core Graveyard :: File Handling, defect)

Description

[Henry Goffin]

Here is a scenario which describes the problem perfectly:

A PHP script is used to generate downloadable files.  These files do not match 
a registered MIME type but should be considered application data (in the cas of 
my website, they are level maps for Warcraft III).  These files have a specific 
filename extension (.W3M).  The PHP script generates the following headers, as 
well as a Content-Length header and then the datastream:

Content-Type: application/x-unknown
Content-Disposition: attatchment; filename="(2)Island Hopper.w3m"

Problem - the Save As dialog lists the filename as "(2)Island Hopper.w3m.php" 
and the file type as "PHP File (*.php)".

Expected - the Save As dialog lists the filename as "(2)Island Hopper.w3m" and 
the file type as either "W3M File (*.w3m)" or "Unknown (*.*)"

This is affecting a fairly major site, and I cannot find a way to work around 
it.  Please do not tell me that I am using the wrong MIME type, or that I 
should not be using quotes on the filename, because I have studied the relevant 
RFCs very carefully.  I would prefer to use the octet-stream MIME type, but 
that causes Mozilla to append a ".exe" suffix, which is far worse than ".php" 
for me.

And please do not close this as a dupe of bug 120327, which is very much 
related (at some points in its evolution) but not the same.  If anything, 
120327 is lost and directionless after 300+ comments, and could possibly be 
marked as a dupe of this.

Comment 1

[Kai Lahmann (is there, where MNG is)]

Henry: this IS a dup of 120327.
Also, whcih version do you use? (is the patch already in there..?)

Comment 2

[Kai Lahmann (is there, where MNG is)]

I think this hits it even better (haven'd read the "Content-disposition")

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

Comment 3

[Henry Goffin]

This is not exactly a dupe of bug 65827 either, though thanks for pointing me 
to that one.

That bug concerns a *known* MIME content-type, with Mozilla appending what it 
thinks is the right extension.  This bug concerns a unknwon MIME type (for 
example, application/x-warcraft3map) and Mozilla is automatically appending 
the .PHP suffix from the script's filename.

They have similar consequences but I believe that it is two seperate bugs at 
work.  There is no way that Mozilla could be picking the .PHP suffix that it 
gives me from the Content-type header.

Comment 4

[Kai Lahmann (is there, where MNG is)]

"<michaell> kail: his argument for it not being 65827 is that it is, in fact, a
dupe of 120327 :)"

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

Comment 5

[Michael Lefevre]

mozilla is taking the extension from the file name because you're giving it an
unknown MIME type.  if you don't want that to happen, the solution is to give it
a known MIME type.  if there isn't one that's relevant, then you should use
application/octet-stream (which would work if bug 120327 was fixed).

as I understand it, fixing bug 120327 will result in the "expected" behaviour
from your report, rather than the "problem" behaviour, and therefore this is a
dupe of it.

the behaviour has been improved somewhat with the patch that's in for 120327. 
are you using a build of mozilla which has that?

Comment 6

[Henry Goffin]

Yes, I have experienced this with Mozilla 1.0, 1.0.1, 1.1 alpha, 1.1 beta, and 
a very recent nightly build.

Pardon me for being obtuse, but this seems like a bug on its own?

We have an unknown MIME type.  The content-disposition is providing a file 
extension.  Mozilla ignores the provided extension and tries to guess the MIME 
type from the name of the script which is generating it.

That seems like erroneous behavior to me ... ?

Comment 7

[Michael Lefevre]

thinking about this again, I'm not sure this wouldn't be better duped to the
other bug after all...

the fact that mozilla ignores the content-disposition and always uses the code
which looks at MIME type (or guesses when it doesn't know) is bug 65827.

the fact that you can't fix it by changing the MIME type is bug 120327.

what you are describing are slightly different symptoms, but the bugs are those
which are already filed.  and it is most certainly erroneous behaviour - we're
not saying your report isn't valid, just that it is covered by existing bugs.

Comment 8

[Henry Goffin]

Thank you for the explaination :)  I can see a lot of (perhaps entirely too 
much) internal discussion about 120327, and while several different fixes have 
been proposed, nothing substantial has been done.  I wonder if it would be 
worth my time to read up on Moz's internals and submit a patch...

Anyway, I've worked around these bug now that I can see it won't be fixed for 
months, if not years.  I'm not happy with it, but generating a temporary unique 
URL for the content and then redirecting the browser by META refresh seems to 
work.  Sigh.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Henry, this should in fact get fixed when I fix bug 65827....  And it'll
hopefully take less than months (and definitely less than years).