62761 - Content-Disposition: attachment;filename behaves inconsistently

Status: VERIFIED DUPLICATE of bug 62760

(Core :: Networking: HTTP, defect, P3)

Description

[jsp]

Setting the "Content-Disposition: attachment; filename" HTTP header causes
inconsistent results on the Macintosh, apparently depending on the URL of the
host(!).

Here's the situation: I have a program that can be built as a CGI executable, an
ISAPI DLL, or an ASP-accessible COM object.  Regardless of how it's built, it
sets the content-disposition header the same way.  It also sets Content-Type:
application/octet-stream.  The intent is to get the browser to offer to save the
response, which is in fact an XML document representing some data that the user
has indicated s/he would like to save.  I've inspected the headers and the
response body, and they are substantially the same regardless of which version
of the program generates them.  (IIS adds a Set-Cookie header and a
Cache-Control header when I use the ASP version, but these should not affect the
desired behavior.)

What happens is that Mozilla (2000121112) behaves as desired if the response
comes from the CGI version.  It pops up the "Downloading" dialog, and if I opt
to save to disk, bring up a "Save" dialog with the filename I specified in the
"Name:" field.  So far, so good.

If the content comes from the ISAPI DLL, Mozilla silently saves a file on the
desktop with a name like "u5pidxja.dll."  The file's content is correct.

If the content comes from the ASP, Mozilla pops up an "Unknown File Type" dialog
instead of the "Downloading" dialog.  If I choose "Save File...", the "Save"
dialog appears, again with the specified filename preloaded.

The problem appears to be Mac-specific.  If I run Mozilla on Windows, it doesn't
matter which version of the program generates the response; I always get the
desired behavior.

For what it's worth, IE 5 behaves as desired on Windows. On the Mac, it appears
to ignore the Content-Disposition header altogether, and displays the XML.

Unfortunately, I can't post a public URL that demonstrates the problem, because
the application is still under development.  I'd be happy to respond to email
requests for a temporary address.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Stephen Walker]

vrfy dup