Closed Bug 62760 Opened 24 years ago Closed 21 years ago

Content-Disposition: attachment;filename behaves inconsistently


(Core Graveyard :: File Handling, defect)

Not set


(Not tracked)



(Reporter: jsp, Assigned: Biesinger)




(2 files)

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

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.


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

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.
Ever confirmed: true
nominating for moz 0.9
Target Milestone: --- → mozilla0.9
setting milestone = future (for now)
Target Milestone: mozilla0.9 → Future
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.
Keywords: nsbeta1
Target Milestone: Future → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla1.0
-> mscott (mr. content-disposition)
Assignee: darin → mscott
Blocks: 104166
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

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?
Target Milestone: mozilla1.0 → mozilla1.2
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
'' 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 '' 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
 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. 
Blocks: 155949
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."
No longer blocks: 155949
Not sure if it's the same problem or not, but see Bug 163755
Content-Disposition: attachment -> File handling, per bz.
Assignee: mscott → law
Component: Networking: HTTP → File Handling
QA Contact: tever → cpetersen0953
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by 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".
OS: Mac System 9.x → All
Hardware: Macintosh → All
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.
Closed: 21 years ago
Resolution: --- → 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.
Resolution: WORKSFORME → ---
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
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
>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)
Assignee: law → file.handling
Keywords: mozilla1.0helpwanted
Priority: P3 → --
Target Milestone: mozilla1.2alpha → ---
taking, have a patch
Assignee: file-handling → cbiesinger
Keywords: helpwanted
Target Milestone: --- → mozilla1.7alpha
Attachment #136455 - Flags: review?(bz-vacation)
Comment on attachment 136455 [details] [diff] [review]

Yeah, that looks good.	r=bzbarsky.
Attachment #136455 - Flags: review?(bz-vacation) → review+
Attachment #136455 - Flags: superreview?(darin)
Comment on attachment 136455 [details] [diff] [review]

Attachment #136455 - Flags: superreview?(darin) → superreview+
thanks, checked in

Checking in nsHelperAppDlg.js;
/cvsroot/mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js,v  <-- 
new revision: 1.55; previous revision: 1.54
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.