62760 - Content-Disposition: attachment;filename behaves inconsistently

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

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]]

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

Comment 2

[Darin Fisher]

reporter, it would help considerably if you could tell me what URL's you are
entering, as well as what HTTP headers you get in response for each URL.

the process of content handling depends on both the content-* headers as well
as the file extension that may appear in the URL.

thx.

gordon: cc'ing you for mac expertise.

Comment 3

[jsp]

I can't post an URL in a public place like this, but I'll provide a temporary
address in response to an email request.

As for the headers, they vary slightly:

--- Start CGI or ISAPI headers ---
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Web, 13 Dec 2000 15:10:44 GMT
Content-Type: application/octet-stream
Content-Length: 234
Content-Disposition: attachment; filename=filename.xml

--- End CGI or ISAPI headers ---

--- Start ASP headers ---
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Web, 13 Dec 2000 15:10:44 GMT
Content-Disposition: attachment; filename=filename.xml
Connection: Keep-Alive;
Content-Length: 234
Content-Type: application/octet-stream
Set-Cookie: ASPSESSIONIDGGQGGWQQ=JCDJOHMDBNBNGLLBAIDLKMOB; path=/..
Cache-control: private

--- End ASP headers ---

Of course, the date and cookie are variable.

I use the usual extensions: .exe for the CGI, .dll for the ISA, and .asp for the
ASP.  I wondered if the URL's file extension was entering into the equation
somehow, but this seemed rather astonishing.  On further reflection, I can see
how extensions would be useful in determining the file-type for the Mac,
especially if you've got a generic content-type like octet-stream.  However, the
extension of a filename in the content-disposition field should probably get
priority over an extension parsed from the URL, as it may provide an explicit
indication of the server's intent.

Note that in the best of all possible worlds, I'd specify a content-type of
text/xml, but this causes Mozilla to ignore the content-disposition altogether
and display the document on both Windows and the Mac.  (In my opinion, it
shouldn't.  IE 5.x for Windows always pops up a downloading-type dialog box if
Content-Disposition is set, which is the behavior I'm after.)  Since NS 6 is out
there with this behavior, I'm stuck with application/octet-stream for now, but
I'd like to switch to text/xml down the road.

Comment 4

[Darin Fisher]

This is very interesting.  I agree that it seems like the Content-Disposition
is not being properly handled.  As far as whether or not Content-Type should
override Content-Disposition (or the other way around), I think I need to
check the HTTP spec to see what if anything it has to say on the matter.

Comment 5

[jsp]

RFC 2616 (HTTP/1.1) is a bit vague on this. It says, "If this header is used in
a response with the application/octet-stream content-type, the implied
suggestion is that the user agent should not display the response, but directly
enter a `save response as...' dialog." It says nothing about how other content
types should be handled.

However, RFC 2183 ("The Content-Disposition Header Field") says, "Bodyparts can
be designated `attachment' to indicate that they are separate from the main body
of the mail message, and that their display should not be automatic, but
contingent upon some further action of the user." RFC 2183 "provides a mechanism
whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC
2047, RFC 2048, RFC 2049] can convey presentational information." I think HTTP
messages conform to the MIME specifications, so this RFC can legitimately be
applied.

That said, I think "there is no controlling legal authority" regarding the
appropriate behavior, just hints.  From my perspective, though, it's very
desirable for content-disposition to get top priority.  I don't think there's
anything in the RFCs that prohibits that, and the hints tend to favor that behavior.

Comment 6

[Keyser Sose]

I am going to mark NEW to get this off our unconfirmed radar while you guys discuss it.

Comment 7

[Darin Fisher]

nominating for moz 0.9

Comment 8

[Darin Fisher]

setting milestone = future (for now)

Comment 9

[jsp]

One of the things that bothers me about this bug is that Mozilla appears to base
its behavior on the URL. If this is because Mozilla inspects the URL to
determine the media type, it violates RFC 2616: "If AND ONLY IF [my emphasis]
the media type is not given by a Content-Type field, the recipient MAY attempt
to guess the media type via inspection of its content and/or the name
extension(s) of the URI used to identify the resource." We specify the
content-type, so Mozilla is not allowed to guess.

Comment 10

[Darin Fisher]

-> mscott (mr. content-disposition)

Comment 11

[jsp]

For what it's worth, this now behaves badly with Windows builds, too. Only
downloads from a CGI executable (.exe extension) behave as desired, causing a
File Save dialog to pop up primed with the appropriate file name. Downloads from
 an ASP (.asp extension) result in a dialog with a caption like "Downloading
frammitz.asp" that indicates that I'm trying to download a file of type '"ASP
auto file" [text/html]' and offers to let me open the file with asp_auto_file or
save it to disk. Mozilla appears to be using the content-type of the current
page rather than that of the response. (Not that this should matter, given a
content-disposition indicating that the file is an attachment.) If I elect to
override the default action (Open) and save the file instead, the File Save
dialog pops up appropriately primed. Similar behavior occurs with ISAs (.dll
extension).

Again, while I have my druthers about how Mozilla handles attachments, I think
it's very bad for this behavior to be dependent on the URL of the page from
which the download is initiated. At the very least, it should be consistent.

Comment 12

[Rudolf Balada]

This bug might tightly connected to bug 98360

Comment 13

[jsp]

The discussion at bug 98360 motivated me to try this out on M0.9.7 on MacOS 9.2.
I can no longer reproduce the original problem; all three variants (CGI, ISAPI,
ASP) produce the same behavior. However, the behavior differs slightly from the
behavior of the Windows version. On Windows, the common file save dialog comes
up. On the Mac, I get the "Downloading [whatever]" dialog, and once I choose to
save the file rather than opening it, I get a save dialog.

I think either behavior is defensible. The Mac's gives the user more control at
the expense of additional clicks. If my argument in bug 98360#c16 is valid, the
Mac's approach is better. I don't have a strong preference; even the somewhat
differing behaviors doesn't really bother me.

Comment 14

[jsp]

Shucks. I was hoping the comment number (16) would be part of the bug number link.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Do the behaviors still differ if you open

Edit > Preferences > Navigator > Helper Applications

and click the "Reset" button on the bottom right of the panel?

Comment 16

[jsp]

I misstated the current status in comment 13. The behavior on Windows remains
inconsistent, as described in comment 11. MacOS 9 and OS X behave consistently
(if less than ideally, from my point of view), always bringing up the
Downloading dialog with "Save this file to disk" selected.

Resetting the Help Applications preference makes no difference on any platform.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Ok... On windows, could you please set the environment variable NSPR_LOG_MODULES
to "nsHttp:5", set the environment variable NSPR_LOG_FILE to some filename,
start up Mozilla, load one of the pages in question, quit, change the
NSPR_LOG_FILE name, repeat with the other page.

Then attach both files to this bug?

Comment 18

[Jungshik Shin]

A little bit of new(?) data point.....
When C-T is set to 'application/octet-stream' and the cgi program
to produce the output ends with '.pl', Mozilla(Win2k) suggests
'cginame.pl.exe' as the filename to use in 'file save dialog box'.
If C-T header is set to 'application/x-jshin' (to make sure it's
NOT known to mozilla), Mozilla(win2k) lets user choose among
'open, save, cancel' and suggests 'cginame.pl' when I choose 'save'. 

There's another problem with handling of 'filename' parameter.
It seems like Mozilla isn't compliant to RFC 2231(2184) when parsing
C-D http header (see
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamTransfer.cpp#108)
 although it's compliant to RFC 2231 in parsing
mail/news header. I'll file a separate bug for this. Of course,
until this bug is fixed, fixing a bug I'm gonna file has absolutely
no effect. 

Comment 19

[Boris Zbarsky [:bzbarsky]]

That .exe thing is bug 120327.  Nothing to do with this bug.  Can people
actually reproduce _this_ bug?  Note that doing so requires Mozilla on Mac,
three different server-side solutions, etc.

Comment 20

[jsp]

I can still reproduce this bug on Windows 2000, as described in previous
comments. The behavior on the Mac is consistent and defensible. Perhaps it's
worth summarizing what happens.

On Mac OS X, the behavior is consistent, regardless of URL extension. The
"Downloading [whatever]" dialog is displayed with "Save this file to disk"
checked. When I click "OK," a dialog titled "Enter name of file to save to..."
appears with the name specified in the Content-disposition header in the "Save
as:" box. While this is slightly less than ideal for my application (it requires
an extra click on the Downloading dialog), I think it's better than skipping the
Downloading dialog, because that would diminish the user's control.

On Windows 2000, the behavior depends on the URL extension, and it's never as
good as it is on the Mac. If the extension is ".asp" or ".dll," a "Downloading"
dialog comes up, but the default option is "Open using..." rather than "Save
this file to disk." If the extension is ".exe," the Downloading dialog is
skipped, and the "Enter name of file to save to..." dialog comes up.

Bottom line: the bug has morphed a bit. Mac OS X now behaves consistently, but
Window behaves inconsistently. I think the Mac's behavior is appropriate and
should be implemented for Windows.

Comment 21

[jsp]

Attachment: Log files for problematic transactions

This attachment is a belated response to comment #17. It's a zip file (since
Bugzilla won't accpet non-patch files larger than 150K) with four logs in it:

- cgi1.log reflects a request for a page from which I can issue a request to a
CGI script (.exe) that will generate a response that demonstrates this bug's
problem. It's included in case it will help discern the relevant lines in the
next log, since the only way I can issue a request that will generate a
problematic response is by first loading a page.
- cgi2.log includes data about the same initial request and response as
cgi1.log, as well as data about a request for the problematic response and the
response itself.
- dll1.log corresponds to cgi1.log. The requests are directed to an ISAPI DLL
(.dll) instead of a CGI script.
- dll2.log likewise corresponds to cgi2.log.

Comment 22

[Boris Zbarsky [:bzbarsky]]

The windows behavior is due to a security check (if the file looks like an
executable, we do not allow opening it directly but force a "save" instead). 
What's the default helper listed for .dll and .asp files in your case?

This is definitely related to bug 98360 but is not necessarily going to be
completely fixed by that bug... Though I'll try to make it so that it is.

Comment 23

[jsp]

On my Win2K system, the default helper for .asp is "asp_auto_file." For .dll,
it's "dllfile."

Comment 24

[Brad Clarke]

Not sure if it's the same problem or not, but see Bug 163755

Comment 25

[benc]

Content-Disposition: attachment -> File handling, per bz.

Comment 26

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 27

[Boris Zbarsky [:bzbarsky]]

Is this an issue with a current (1.6a trunk) build?

Comment 28

[jsp]

I tested this with 1.5rc2 and 20031014 trunk builds on Windows and MacOS X. 
Here's what I found:

- 1.5rc2 on Windows and OS X and 20031014 on OS X: the downloading dialog (now
titled "Opening <filename>" on both OSes) always opens (regardless of whether
the extension on the URL is .asp, .dll, or .exe), with "Save it to disk" the
default option.
- 20031014 on Windows: the downloading dialog always opens, with "Open it with
the default application (xmlfile)" the default option.

For my purposes, the new (20031014) behavior ("Open it") is less useful than the
old ("Save it").  In fact, the 1.5rc2 behavior looks fine to me.  I'd more or
less forgotten about the issue, which may mean that it's been working the way
I'd like for some time.

Comment 29

[jsp]

FWIW, some quick testing indicates that this has been working the way I prefer
since 1.3. 1.2.1 almost got it "right", but it skipped the downloading dialog
and went straight to a save dialog if the extension was .exe.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Sounds like this is no longer inconsistent, in any case.  So this bug is worksforme.

Comment 31

[jsp]

I didn't mean to give that impression.  It works consistently from 1.3 through
1.5rc2, but the behavior of 20031014 for Windows is different from the previous
behavior (which 20031014 for OS X matches).  I prefer the old, consistent
behavior, so I don't think this is resolved.

Comment 32

[[e-mail]]

jsp: I do not understand what exactly the problem is and what the inconsistency
is - could you give details on what you think is wrong with the current
nightlies in that respect? 

Comment 33

[jsp]

See comment #28.  The difference is that 20031014 for Windows has "Open it with
the default application (xmlfile)" as the default option, rather than "Save it
to disk", which is the default for older versions and 20031014 for OS X.

In my mind, there are reasons this is problematic:
1) The browser behaves differently on different platforms, for no obvious reason.
2) I think the old behavior was preferable.

If someone else has made a case for changing the behavior, I haven't heard it. 
If no such case was made, the old behavior was presumably adequate, which the
new one may or may not be.  In this case, it seems safest to keep things as they
were.  If a convincing case has been made for the change, presumably it should
be implemented on all platforms.

This is definitely a fit-and-finish issue; users can get the job done with
either behavior, since it's just a question of which radio button is checked by
default.  I find it amusing, though, that on my machine, recent Mozilla builds
will by default fire up IE to process an XML attachment.

Comment 34

[Boris Zbarsky [:bzbarsky]]

> 1) The browser behaves differently on different platforms, for no obvious
> reason.

The "obvious reason" is that one platform has an application registered to
handle the type, and the other platform does not.

But we did use to always check the "save" checkbox before bug 193698 landed.  I
assume the change biesi made there was purposeful (and that I asked him offline
about it at the time, but I can't recall the conversation).

Comment 35

[jsp]

On both my Mac and my Wintel box, another program is registered with the
operating system (but not Mozilla, according to the Helper Applications pref
dialog) to handle XML files.  I still don't see any obvious reason why Mozilla
should behave differently on the two platforms.  Is there someplace else I
should look?

I hope biesi will explain why "save" is no longer checked unconditionally.  If
it is indeed purposeful, shouldn't Mozilla behave similarly on my Mac and Wintel
boxes, given their similar configurations?

Comment 36

[Boris Zbarsky [:bzbarsky]]

on Mac, what is the program really registered to handle (in Internet Config)? 
"XML files" is not a well-defined concept on mac... (on Windows it means ".xml
extension").

Comment 37

[jsp]

I'm not a Mac expert, so please bear with me.  If I use Mozilla to save a
downloaded XML file to disk, it gets associated with ("opened with") Safari.  I
determined this by opening the Info window for the downloaded file.  I can't
find any other indication of file-type associations.  I looked in the the
"Internet" settings in System Preferences.  Is that what you meant by "Internet
Config?"

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

>I assume the change biesi made there was purposeful (and that I asked him offline
>about it at the time, but I can't recall the conversation).

Ah. right. I think the idea was that the helper app dialog should know what the
real state of the nsIMIMEInfo is. I think I talked with you about that too, but
I'm not sure...
I can't remember if I intended an actual frontend change. I seem to recall that
I wanted to add code to nsHelperAppDlg.js to still default to "Save" - looks
like I didn't do that. doing so would be fine with me, certainly - as long as it
is done in nsHelperAppDlg, not in exthandler; this seems to me like a decision
that the frontend should do, not the backend.

(sorry that I didn't see that indirect question to me earlier, I didn't have
much time to read my bugmail lately)

Comment 39

[Boris Zbarsky [:bzbarsky]]

Yeah, I think we should make that UI change in nsHelperAppDlg.  I agree that
that's a UI issue, not a back end one.

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

maybe I should add that I will not have the time to make such a patch myself in
the near future

(while I'm causing bugmail anyway, -> default owner)

Comment 41

[Christian :Biesinger (don't email me, ping me on IRC)]

taking, have a patch

Comment 42

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 43

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136455 [details] [diff] [review]
patch

Yeah, that looks good.	r=bzbarsky.

Comment 44

[Darin Fisher]

Comment on attachment 136455 [details] [diff] [review]
patch

rs=darin

Comment 45

[Christian :Biesinger (don't email me, ping me on IRC)]

thanks, checked in

Checking in nsHelperAppDlg.js;
/cvsroot/mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js,v  <-- 
nsHelperAppDlg.js
new revision: 1.55; previous revision: 1.54
done