Downloading from a CGI whose output specifies a Content-Disposition: attachment; filename="foo.txt" header no longer works




9 years ago
9 years ago


(Reporter: edwardjsabol, Unassigned)


3.5 Branch

Firefox Tracking Flags

(Not tracked)




9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20091102 Firefox/3.5.5

I've developed an intranet-only CGI application which outputs in a variety of different formats based on user-selection. Specifically, it can output in HTML, plain text, and Excel formats using (mod_perl) code like the following:

	  $r->header_out("Content-Disposition" => qq{attachment; filename="${filename}.xls"});
	  print $ss->data;

This worked just fine in all Firefox and Mozilla versions prior to 3.5, and it works fine in Safari, Chrome, Opera, and Internet Explorer.

In Firefox 3.5.x (and confirmed with latest 3.5.5), when I click on the link to download either plain text or Excel format, I get the usual dialog which says

You have chosen to open
which is a: plain text document

What should Firefox do with this file?

( ) Open with ....
(x) Save File


When I click the "OK" button, the dialog goes away, but nothing happens. I would expect the downloaded file to appear in my downloads directory and for an entry to appear in the Downloads window logging the details of the download, but the file doesn't appear and nothing is displayed.

Upon further investigation, I noticed that a temporary file is created at /tmp/RANDOMSTRING.types.part which contains the download.

In previous versions of Firefox, the file would appear in my downloads directory and in the Downloads window with the file name specified by the server (foo.txt in the example above).

Reproducible: Always

Steps to Reproduce:
1. Download a non-HTML content type from a CGI with Content-Disposition:attachment; filename="foo.txt" header
2. Click the radio button next to "Save File" if that's not already selected.
3. Click the "OK" button.
Actual Results:  
File is not downloaded to the downloads directory, and no entry appears in the Downloads window. A temporary file is left at /tmp/RANDOMSTRING.types.part.

Expected Results:  
The file should download to the configured downloads directory and an entry should appear in the Downloads window logging the details of the download.

This as a regression from all versions of Firefox prior to 3.5.

I tested it on Mac OS X, and the problem did NOT occur there. This is apparently a Linux-only problem. I haven't tested on Windows.

Tested on RHEL 5.3.

Comment 1

9 years ago
I just noticed the following output on stderr when testing in safe mode:

*** exception in validateLeafName: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsILocalFile.create]"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: file:///software/linux/usr1/local/firefox-3.5/components/nsHelperAppDlg.js :: anonymous :: line 292"  data: no]

The "Save files to" directory specified in Firefox Preferences -> Main is definitely writeable....
Version: unspecified → 3.5 Branch
Your reports looks like bug 429827 (the exception in comment #77 is the same)

Comment 3

9 years ago
Maybe, although that exception appears to be from Thunderbird and the line number is different.

Also, I'm 100% positive that my exists and is writeable. It's not on an external drive either. *shrug*

I'll see if I can apply that bug's patch to see if it helps though. Thanks for the pointer.
Do you have this issue only with your downloads or with all downloads ?
What happens if you change the preferences for the file save to ask every timer where to download the file (no default location) ?

Comment 5

9 years ago
Belated follow up on this bug.... It turns out I think this was due to a corrupted sqlite file in my profile. Actually, I think pretty much all of the sqlite files in my profile were corrupt. I deleted the ones that were corrupt and the problem went away when I restarted Firefox. Closing this bug. Thanks for taking a look, Matthias.
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.