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.

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

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.

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.

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.

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.

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

nominating for moz 0.9

setting milestone = future (for now)

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.

-> mscott (mr. content-disposition)

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.

This bug might tightly connected to bug 98360

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.

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

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?

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.

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?

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.

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.

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.

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.

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.

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

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

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

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".

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

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.

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.

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

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.

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?

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.

> 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).

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?

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").

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?"

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

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

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)

taking, have a patch

Comment on attachment 136455 [details] [diff] [review] patch Yeah, that looks good. r=bzbarsky.

Comment on attachment 136455 [details] [diff] [review] patch rs=darin

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