Closed Bug 300169 Opened 19 years ago Closed 11 years ago

download shows file suffix as file type instead of Content-Type

Categories

(Firefox :: File Handling, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: js021104, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

This is similar to #282910. The firefox-0.8 and before doesn't have this
problem. I am not sure if firefox-0.9 has this problem. But 1.0 and 1.04 as well
as the newest build have this problem.

I use a perl script to send file of different types, such as application/pdf,
video/quicktime, image/jpg etc. The image files are hadled correctly by the
browser, i.e. they are displayed in the window. But for pdf files, the download
window shows up (as it should be), but the file type is shown as PL. Since the
firefox-0.8 handles it correctly, I am quite sure the server have sent the
correct Content-Type. To make it absolutely sure, I used a perl script (instead
of browser) to request the same URL and got the following header fields:
200
Connection: close
Date: Sat, 09 Jul 2005 05:20:25 GMT
Server: Apache/1.3.26 (Unix) mod_perl/1.27
Content-Length: 26237
Content-Type: application/pdf
Client-Date: Sat, 09 Jul 2005 05:20:26 GMT
Client-Peer: 192.168.1.3:80
Client-Response-Num: 1

Looks like the download part mishandled the Content-Type and file suffix.

Reproducible: Always

Steps to Reproduce:
1.server side: set up a perl script to send a pdf file with a header 
Content-Type: application/pdf
2.use firefox browser to browse the script
3.

Actual Results:  
In download window, it shows PL file type.

Expected Results:  
It should show application/pdf file type.
Are you able to reproduce this with the latest Firefox trunk build?

If not, please resolve the bug as WORKSFORME.

Thanks!
Whiteboard: CLOSEME 09/30
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I'm using Firefox 2.0.0.4. It works for PDF now but still has the same problem with other content type, e.g. application/x-dvi. The download dialog shows the content type is 'PL' since I'm using a .pl file to download files. I have checked the Content-Type: header which is set correctly.

I set the resolution to WORKSFORME last night after testing the PDF download. However I found the problem persists today when tested a dvi file. I change
the resolution to INCOMPLETE. Don't know if this is appropriate.

Thanks.
Resolution: WORKSFORME → INCOMPLETE
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
It is not a security bug, so it will not be fixed in Firefox 2. Trunk will become Firefox 3, so please try to reproduce the bug with the latest trunk build.
You can download one here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

And no, INCOMPLETE is probably not the appropriate resolution -- it would be, if you had not answered. You can read the resolutions' description by clicking the “Status” link next to it.
Just to be safe: don't start trunk with your 2.x profile -- create a new profile. 
I guess you have seen the bug with a clean profile on 1.x - 2.x, too.
Thanks.
I've downloaded the 3.x trunk. But it may take a while for me to run it since I don't have the required libstdc++.so.6 installed. Mine is .5. I'll fake one to see if it works or not. If not I'll have to install the .6 lib. Thanks.
Just tested the new 3.x trunk (on Windows). It was a fresh test (new user). The problem remains the same. It showed PL file type for Content-Type: application/x-dvi. Thanks.
Whiteboard: CLOSEME 09/30
Version: unspecified → Trunk
Can you provide a URL that exhibits this problem?  This type of thing is done all over the internet and (in other cases) works fine -- bugzilla does this with attachments.
I can certainly get around this by setting a handler for the type. Actually I had already forgot about this before receiving the email. I noticed this problem when I upgraded the firefox from 0.8 and I used both 0.8 and 1.x to point to the same 
URL in my local setup. I cannot provide a URL right now. The following is a perl script that I used to test. Make sure to edit it for the file name. Also make sure that NO handler is set for the application/x-dvi.
#!/usr/bin/perl
#this is a test script to download a file with
#"Content-type:" field set correctly. 
#CGI version

use strict;
use CGI;

#set this to a dvi file (or some other type).
my $fpath=".dvi";
#file content type
my $mtype = "application/x-dvi";
#get the file size
my @fst=stat($fpath);
my $fsize = $fst[7];

my $q = new CGI;

print $q->header( -type	=> $mtype,
		  -length => $fsize);

open(FIN,$fpath);
while(<FIN>)
{
    print $_;
}

OK, I see this with SeaMonkey 1.1.1 (gecko 1.8.1.2) but not with SeaMonkey 1.1.2 (gecko 1.8.1.4) or later.  So, I'd expect FF 2.0.0.4 and later builds to work (a current branch build does work OK).
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110515 Minefield/3.0a9pre

I've tested with php script changing filetypes and mime-types, on some of them it shows Type of file (e.g. GIMP image or 7zip file) on others just PHP file
I wonder if this could be related to bug 299372
Reporter, are you still seeing this issue with Firefox 3.6.8 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2010-09-15]
(In reply to comment #12)
> Reporter, are you still seeing this issue with Firefox 3.6.8 or later in safe
> mode? If not, please close. These links can help you in your testing.
> http://support.mozilla.com/kb/Safe+Mode
> http://support.mozilla.com/kb/Managing+profiles

Just downloaded/installed 3.6.8. The problem remains (not in safe mode).
I tested again with a perl client script pointing to the same URL. The firefox
showed "pl" type, which is my file's suffix. The perl script printed
...
Content-Type: application/x-dvi
...

For some reason, firefox didn't pick up the Content-Type in this case.

I couldn't start firefox in safe mode. I got this:

Inconsistency detected by ld.so: dl-open.c: 603: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!
No reply, INCOMPLETE. Please retest with Firefox 3.6.10 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago14 years ago
Resolution: --- → INCOMPLETE
(In reply to comment #14)
> No reply, INCOMPLETE.

Not no reply, reUNCOd.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Whiteboard: [CLOSEME 2010-09-15]
I think this works in cases when the script sends both content-type and sends a filename header with matching extension.

In other words, firefox does not handle content-types, only file extensions.
This is still the case. A simple test is to use the api from wikipedia:
http://en.wikipedia.org/w/api.php?action=opensearch&namespace=0&suggest=&search=sq
This returns data with "Content-Type: application/json; charset=utf-8"
Yet the download dialog shows:

api.php
which is a: php File

#491869 is a duplicate of this bug.

Firefox 6.0.2
Still present in Firefox 7. Another common use case is when websites mark files as application/octet-stream to force downloading them: this doesn't work with Firefox since the file is detected as PDF nonetheless. A simple test is to download this file:
http://www.persee.fr/articleAsPDF/estat_0336-1454_2006_num_393_1_7148/article_estat_0336-1454_2006_num_393_1_7148.pdf
Bug 613727 has more information from developers. Apparently detecting from file contents (not extension) is the wanted behavior *if the content type is not provided*. They don't say what should happen when it's specified as application/octet-stream, though, 

There's also a comment on how Thunderbird handles application/octet-stream files there:
https://bugzilla.mozilla.org/show_bug.cgi?id=559014#c5

...and bug 647633 about not asking about opening application/octet-stream files at all.
...and bug 560832 about this issue with PDF.
Closing this bug. If anyone can still reproduce this issue, please reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.