Closed Bug 65827 Opened 24 years ago Closed 21 years ago

File extension (.php) determined from Content-Type header (or url extension) overrides filename in Content-Disposition header.

Categories

(Core Graveyard :: File Handling, defect, P1)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: rajeshwarrao, Assigned: Biesinger)

References

Details

Attachments

(2 files, 1 obsolete file)

source of testcase at http://www.zbarsky.org/cgi-bin/shell1.sh
(deleted), text/plain
Details
patch v2
(deleted), patch
bzbarsky
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
Our web enabled product is developed using CGI. Netscape6 does not work properly when we use the http response tags (in the shell script) Content-Type: Application/octet-stream Content-Disposition: attachment; filename="abc.xyz" Download dialog (Save to disk option) does not give the default file name as abc.xyz instead it gives name of the shell script being run on the server i.e name of the script in which the above tags are being used We want the solution as soon as possible. It's fine with Netscape4.7
Worksforme with linux Mozilla build 2001-01-16-08. The default filename is given as "abc.xyz" (with the quotes; the quotes should not be there according to RFC 1806 if you just want the filename to be abc.xyz)
This bug can be reproduced (simulated again)on Netscape6(for NT)using CGI at server end. I give you the sample script which we are running in the cgi-bin of our Netscape Web Server and the client is NT with Netscape6 browser. Name of the script say shell1.sh ************************************************************* #!/bin/sh cat <<EOM Content-type: application/octet-stream Content-Disposition: attachment; filename=file1.abc <html> <head><title>Testing PDM@Net</title></head> <body> Test not succesfull! </body> </html> EOM **************************************************************** If you save the attachment then default file name will be "shell1.sh" not "file1.abc" rajeshwarrao@hclt.com
Ref:Earlier comments It can be reproduced when we add this Content-Type Application/octet-stream as a part of Multipart/mixed ...
rajeshwarrao@hclt.com, the example you give in this bug is invalid, since a blank line signals the end of the headers and thus the content-dispositon header is never encountered. When I remove the blank line before the content-disposition header, things work as they should. I _do_ see the failure in the case when the attachement is a part of multipart/mixed. I've set up a testcase with the file you sent me at http://www.zbarsky.org/cgi-bin/shell1.sh (and I will attach the source of that testcase to this bug). Since I can confirm this on Linux (build 2001-01-16-08), setting OS to all, status to NEW, over to networking.
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
OS: Windows NT → All
QA Contact: doronr → tever
Summary: HTTP response tag Content-Disposition does not work properly → Content-Disposition header ignored for part of multipart/mixed content
Adding dependency to meta bug
Blocks: 61688
Get rid of the quotes around the filename - that worked for us to fix the same problem (N6 would just sit there after you select "Save to Disk" rather than display a "Save File As" dialog box). As a side note, be sure and test your site with IE5.5(SP1) because we've found that that one does not like explicitly specifying "attachment" (go figure). But, N6 apparently does require it so you're stuck with tradeoffs and/or conditional code. At least that's what we've seen, FWIW.
Shouldn't the test script include a terminating boundary like ---SWEBOUNDARY--
I've added a terminating boundary to the testcase (indeed, there should be one). This does not fix the problem.
*** Bug 67984 has been marked as a duplicate of this bug. ***
Here's another testcase. Mozilla doesn't pick up the filename but IE does. Build 2001022209, win2000: http://www.bewley.net/perl/download.html
Actually, it looks like Mozilla DOES pick it up for *saving*, but DOES NOT pick it up for opening the file. This can be demonstrated by opening an MP3 off the web and taking a look at the filename in the player. This is what I got from opening a file named "Down Slow.mp3" (the filename in the content-disposition header, that is): C:\DOCUME~1\MATT\LOCALS~1\TEMP\8mwwd1as.mp3
This is correct, I believe. Mozilla makes a point of saving files to be opened with randomized filenames for security reasons....
Would it be possible to randomize a directory name and then store the file within that directory? I believe that would offer the same amount of security and the convenience of showing the real filename in the application that opens it.
Target Milestone: --- → Future
On build 2001042920. I have the script named index.php that pushes a Comma Seperated file that is designed to be opened MS Excel. In order for Excel to open this file correctly it has to end with a .csv extension. The file name I've explicitly given ends in .csv. BUT since I tell mozilla that this is a application/msexcel type file the random filename mozilla generates end in .XLS because it know it's is an Excel file. This goes back to Excels problem of not being able to recognize Comma Seperated files with a .xls extension properly, but it is also mozilla's fault for changing the extension of the filename that was given. The RFC says that if the filename doesn't pose a security risk (or overwrite another file), then the supplied filename should be used for the temporary file. Mozilla seems to never use the supplied filename and always uses the a random filename. This hurts me because Mozilla changes the extension of the random filename and breaks my relationship with the end application. If I use: header("Content-Disposition: filename=this.csv"); header("Content-type: application/msexcel"); Mozilla opens a file named "fjksdgfhsdg462378.XLS" (or some random name). When it should be opening this.csv as I specifed. When I choose to Save The File instead of opening it, the filename supplied by default is index.php, the name of the script that generated it.
Open Networking bugs, qa=tever -> qa to me.
QA Contact: tever → benc
Changing summary, the bug has morphed.
Summary: Content-Disposition header ignored for part of multipart/mixed content → File extension determined from Content-Type header overrides filename in Content-Disposition header.
One point I'd like to make: When you right-click on a link and say "Save Link As...", we put up the file picker *before* we ever go to the server (and get any http content-type headers). You'll see different behavior when clicking on the link vs. "save link as...". "Fixing" that is harder because we'd have to re-organize the logic to fetch the headers first. So, if you click on the "Try it!" link at http://www.bewley.net/perl/download.html, it will suggest the correct file name. If you right-click that link and choose "Save Link As...", it suggests the name of the script file. There are likely separate issues related to multi-part/mixed.
Mozilla build id 2002050108, windows xp profesional On http://www.linuxiso.org/distro.php?distro=4 +Use "save link as" on link http://www.linuxiso.org/download.php/245/binary-i386-2.iso The only choice in save dialog is exe file. It's really funny. +When we use "save link as" on file don't have extension. For example http://http.us.debian.org/debian/dists/potato/main/disks-i386/current/linux Then the only choice is text file (.txt) +When we use "save link as" on *.bat . The file will be saved as *.bat.txt http://http.us.debian.org/debian/dists/potato/main/disks-i386/current/install.bat
Depends on: exe-san
1.0 RC2 on Linux has the same annoying problem: When I download an executable (xyz.abc) it appends an ".exe" to it (xyz.abc.exe), so I always have to manually remove that again.
Please don't admix bug 120327 to this bug.
*** Bug 160886 has been marked as a duplicate of this bug. ***
-> File Handling (could be HTTP, but I think this is more about correctly interpreting the headers.
Assignee: neeti → law
Component: Networking → File Handling
QA Contact: benc → sairuh
Alias: content-disposition
*** Bug 161992 has been marked as a duplicate of this bug. ***
*** Bug 163026 has been marked as a duplicate of this bug. ***
*** Bug 145750 has been marked as a duplicate of this bug. ***
Also see bug 159833 (progress dialog doesn't display proper information when file is sent as content-disposition: attachment
I fail to see how bug 145750 is a dup of this in light of bug 145750, comment 3. Rather, bug 145750 is a dup of bug 120327 or one of its dependencies.
*** Bug 171481 has been marked as a duplicate of this bug. ***
*** Bug 171663 has been marked as a duplicate of this bug. ***
I've got a situation similiar to several bugs (171481 and 171663) that have been marked as duplicate. The only difference is that I'm using a known MIME type (text/x-vCalendar). One thing I've found is that this *only* effects the Windows version. The Mac OS X version works flawlessly. I haven't had the chance to test on Linux.
Yes... it's the result of a fix for a Windows-only security problem, so it affects only the Windows version.
QA Contact: sairuh → petersen
ok, here's a new one. When I run a file called zip.php, which creates a zip package, and echo's it in the HTML with header data: "Content-Disposition: attachment; filename=zip.zip" It will come out as zip.zip.php Same thing happens with a different file that should be named templates.xmb, but IS BEING named (by mozilla): templates.xmb.php This seems to happen on all builds, and it works correctly on IE5.0+ and Netscape 4.x (6.x+ work on mozilla, so it doesn't work there anymore :P)
Depends on: 147679
*** Bug 180501 has been marked as a duplicate of this bug. ***
Hmm, is anyone working on this? it's 2 years old and for me the most annoying UI bug arround. Anyway I created a test case to help the testing. click here: http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.php source is here: http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.phps The save dialog should have "kilimanjaro-96degrees-04.mp3" and not "kilimanjaro-96degrees-04.mp3.php"
> Hmm, is anyone working on this? No, not really. I plan to once I have time and finish the preliminary work needed, but that could be a few months.
> The save dialog should have "kilimanjaro-96degrees-04.mp3" and not "kilimanjaro-96degrees-04.mp3.php" In my Mozilla (1.1) it suggests the filename "kilimanjaro-96degrees-04.mp3". Seems like it's been fixed then? (Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.1) Gecko/20020827)
This bug is windows-only, lest people are confused.
OS: All → Windows 95
*** Bug 183695 has been marked as a duplicate of this bug. ***
*** Bug 163755 has been marked as a duplicate of this bug. ***
*** Bug 186799 has been marked as a duplicate of this bug. ***
*** Bug 186821 has been marked as a duplicate of this bug. ***
*** Bug 188111 has been marked as a duplicate of this bug. ***
*** Bug 189460 has been marked as a duplicate of this bug. ***
*** Bug 187396 has been marked as a duplicate of this bug. ***
What was the original justification for appending the Content-Type? Is that a W3C spec? (in which case, I'd be all for making the 'invalid' web-sites fix their code instead of Mozilla's! ha) Kudos to Boris et al for finding all the dupes of this bug. It really is a common issue...
> What was the original justification for appending the Content-Type? Bug 116938. Briefly, it's a workaround around a huge gaping security hole in Microsoft Windows. It's a pretty brute-force workaround; this bug is open because we can do better.
*** Bug 183659 has been marked as a duplicate of this bug. ***
*** Bug 170596 has been marked as a duplicate of this bug. ***
*** Bug 186219 has been marked as a duplicate of this bug. ***
ICBW, but I think this is the same bug. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030125 Start here: <http://ww3.weatherbug.com/aws/index.asp> Link "Download Now" contains <http://ww2.weatherbug.com/sponsorsetup/defaultup.asp?secid=1&rnd=27973> click it. Follow the maze of sponsorship qualifications. Arrive at "WeatherBug Installation" page with URI: <http://ww2.weatherbug.com/altdownload.asp?DownloadID=1100&ZCode=&Email=&ZipCode=02893&SCode=1567&STARTCODE=0&BUGSTARTUP=0&RND=8.074566> After a bit, the Enter File to Save To dialog pops up - it wants to save the installer as <minibuginstaller.exe.mp3> In fact, *.exe files are mistaken consistantly for .mp3. My SWAG is that the MIME type in both cases is Application/Octet-stream I don't think the movie will be anything as good as the book!
*** Bug 191314 has been marked as a duplicate of this bug. ***
Summary: File extension determined from Content-Type header overrides filename in Content-Disposition header. → File extension (.php) determined from Content-Type header (or url extension) overrides filename in Content-Disposition header.
*** Bug 191740 has been marked as a duplicate of this bug. ***
Was not able to load http://www.zbarsky.org/cgi-bin/shell1.sh Connection was refused. Sorry. The description of this bug sounds pretty much identical to what I have been experiencing though... You can combine/add my bug report to this one.... Timjor19
*** Bug 192501 has been marked as a duplicate of this bug. ***
*** Bug 193877 has been marked as a duplicate of this bug. ***
*** Bug 194256 has been marked as a duplicate of this bug. ***
*** Bug 195173 has been marked as a duplicate of this bug. ***
*** Bug 184238 has been marked as a duplicate of this bug. ***
Let me add a couple of thoughts. This bug might actually be talking about two seperate bugs. The first bug is the addition of the (CGI type) extension to the name of the file. For example the file abc.xyz is being downloaded using a script called download.cgi and the resulting file name is abc.xyz.cgi. The other bug is similar (but probably not the same). In this second case, the file abc.xyz is being downloaded using a script called download.cgi, and the resulting file name is download.cgi. In both cases the link is being left clicked. I've had the second case in the past. Everything was working on my web server, but on upload to a different server the resulting file name was wrong. It turns out that the problem lay in the CGI.pm module (I was using perl) and that the header for download was incorrect. This was confirmed by printing the header to the log files and comparing them on each server.) The first problem is something I've only recently discovered. It appears to be Windows only and it also appears to have been resolved with the release of Mozilla-1.3. Clients (of mine) where experiencing it and commented. We only have a single Windows server and on donwloading 1.3 I couldn't reproduce. (It wasn't occuring on Linux or Mac). I then downloaded 1.2.1 and the problem was able to be reproduced. I hope this helps shed some light on this bug/there bugs. If what I'm saying is true, it may well be that both have been resolved. The first no longer reproducable in Mozilla-1.3 and the second being related to the CGI software and not mozilla at all.
The first problem still happens to me using Mozilla 1.3.
This perl (plus a little setup) now works great but didn't before 1.3: print "Content-Type: application/unknown\n"; print "Content-Disposition: filename=$file_name\n"; print "\n"; open(FILE, $full_file_path); print <FILE>; close(FILE); 1;
WFM, Mozilla 1.3 (final) on WinNT whereas previous versions did not.
This does NOT work for me with 1.3 final (20030312) with the following Python code: print 'Content-disposition: attachment; filename=%s\n'\ 'Content-type: application/octet-stream\n'\ 'Content-length: %d\n' % (loc, size) try: file = open(BASEDIR+'/'+loc, 'rb') except: errmsg('Couldn\'t access download file!') sys.stdout.write(file.read(size)) file.close()
Ok, I would just like to state the following: this bug only appears when specifying the *wrong* mime-type. I will be using php-scripts to explain. example 1: --- <?php header('Content-disposition: attachment; filename=temp.zip'); header('Content-type: application/octet-stream'); //this won't work, wrong mime-type! $fp = fopen('./temp.zip', 'r'); $contents = fread($fp, filesize('./temp.zip')); fclose($fp); echo $contents; exit; ?> --- This example does NOT give the right mime-type as it's content type. The next example will: example 2: --- <?php header('Content-disposition: attachment; filename=temp.zip'); header('Content-type: application/x-zip-compressed'); //this will work! $fp = fopen('./temp.zip', 'r'); $contents = fread($fp, filesize('./temp.zip')); fclose($fp); echo $contents; exit; ?> --- Now, surprise, surprise, wíll work! why? because the RIGHT mime-type was specified. Next, for mp3, we do the following: example 3: --- <?php header('Content-disposition: attachment; filename=sound.mp3'); header('Content-type: Application/Octet-stream'); //this won't work again!! $fp = fopen('./sound.mp3', 'r'); $contents = fread($fp, filesize('./sound.mp3')); fclose($fp); echo $contents; exit; ?> --- which won't work, and now with the correct mime-type: example 4: --- <?php header('Content-disposition: attachment; filename=sound.mp3'); header('Content-type: audio/x-mpeg'); //this won't work again!! $fp = fopen('./sound.mp3', 'r'); $contents = fread($fp, filesize('./sound.mp3')); fclose($fp); echo $contents; exit; ?> --- tadah! it does work! Basicly, I've tried to show you, that the main cause of this bug is that the script issuing the file returns the *wrong* mime-type.
Go here: http://www.shippysoft.com/scgi-bin/verifykey.cgi?prodkey=discover_demo&type=download Click on 'Download' for Windows and save it to disk. You'll see that it is a .exe file, which as far as I knew, is an octet-stream. The Linux one may be giving the wrong content-type, but I would argue that it shouldn't matter. The browser shouldn't do stuff based on the filename. Otherwise, what's the point of the content-type header? It could just look at the extension and determine what to do, but that is not the role of the browser and that's one reason why we have the headers. The browser should accept whatever type it's given, look in the table of what it should do with it, conclude that it should save to disk, and then use the filename given in the Content-disposition header. It shouldn't try to do any 'guessing' or 'correcting'. Now some may argue that this can open up security holes with the browser accepting what it's told, etc etc, but that's just a whole other can of worms.
Here is one possible solution: Change the "Helper Applications" settings that ship with default installations of Mozilla. From: File Type: application/octet-stream Description: application Extension(s): exe When a file of this type is encountered: Save it to Disk Always ask me before handling files of this type: NO To: File Type: application/octet-stream Description: application Extension(s): When a file of this type is encountered: Open it using the default application Always ask me before handling files of this type: YES I have noticed that there are a quite a few web sites and mail clients (sending mail to Mozilla users) that do not properly match the MIME type and file type. I have found this problem at www.filesdirect.com and some with some emails from www.j2.com. From a usability standpoint, changing the, "application/octet-stream", helper applications settings gives the user the opportunity to decide what they want to do with these files. This is the case with the mail client. I am using Win98 and Mozilla 1.3 build 20030312 and went to the link listed in Comment #66 When I clicked on download button I got the opportunity to save the file (Selected Choice) or (Open with the default application or Open with " ") or cancel. I choose save to disk. The file was correctly saved as an EXE. The save as window indicated the mime type was application/octet-stream. I am not sure how well this will work with some of the other scripts listed for this bug, but it is working well for me.
Ok, I'm trying to get rid of the first problem described in Comment #60. #65 states, that a wrong mime type is used (in fact, this problem dows only occur in the windows-version of mozilla 1.3 (and earlier)). I want to send a csv-file and now I ask myself, which mime-type to use. I tried application/csv, application/x-csv, text/csv, text/x-csv, application/octet-stream, application/unknown, even application/msexcel, however in my opinion I don't want to use such special program names... I even wonder if there is another method or work around for this problem (e.g. using a special header-setting). Changing some default settings within the browser cannot be a solution, because I'm not able to tell this to all our customers.
the mime-type to be used in that case would be: "text/comma-separated-values" http://filext.com/ is a good place to look for the mime-types if you only the know the extension. Tularis
Well, application/octet-stream is the proper extension for .exe files and that's what I use at the address given in comment #66. This still does not work with 1.4 Alpha for me. Ignore the Linux one, I will be fixing that one to be application/x-shar soon, but still, the Windows one does not work. The "What do you want to do with this?" dialog still gives me a .cgi at the end of everything, mostly ignoring my Content-Disposition header. It is still taking the full name of the file, but it keeps adding .cgi to the end.
Guys, we all know what the problem is. We all know what is required to solve it. The problem is finding someone to do the work. In particular, what needs to happen is that the extension-munging code needs to be removed or severely limited, without reopening the security hole caused by the moronic design of 'Launch File' functionality on MS Windows (the fact that ShellExecute is the only way to do it and will happily run executables). One approach to this would be to delay extension-munging to after we know what we're doing with the file. Another is to stop using ShellExecute and deal somehow with the resulting "file not launched in the right helper app" issues. I prefer the first of these, personally. But someone who actually has a Windows system to test on needs to implement it. I may be able to get to it this summer sometime, but I have no Windows system to test on, hence it will take me a good deal of extra effort to do (and I frankly have a hard time caring about the problem, since it does not affect me in any way; I wish people had listened to me when I asked them not to do things this way _before_ the patch went in). The point is, this is a technical problem, which needs a technical solution, and the last comment that was relevant to resolving this bug is comment 23.
In addition to the problem with mismatched file suffix and mime type, there is another bug: I do my things (as a Windows client) like in <a href="#c65">comment 65</a>. Everything works fine except for when i use filenames that contain chatacters with ordinal values above 127; like the characters ä (&auml;) and Ö (&Ouml;). So, this filename works: "Skrap1.doc" ...but this does not work: "Skräp1.doc" Instead, Mozilla suggests my script name and the word extension as the "Save as..."-name: "file-download.php.doc". "Skräp" is swedish and means "rubbish". I have tested my scripts on: Opera 7.10 for Win32 Build 2840 --- Works IE 5.00.3315.1000 for Win32 --- Works Netscape 7.02 for Win32 --- Does not work Mozilla 1.3 for Win32 --- Does not work Mozilla 1.4 Alpha for Win32 Build ID: 2003040105 --- Does not work When I replace &Aring;&Auml;&Ouml; and &aring;&auml;&ouml; with AAO and aao, it works on all of these browsers.
That has nothing to do with this bug.
The problem I have is same as others. When I try to download a file using my cgi program in Netscape7. The file name for example : "a.doc" is suffixed with a ".sh" extension of my cgi script. That is "a.doc.sh". But my content of the file is not hurt. I dont know how to get rid of this. I have a request to the author of "Comment #72 From Jonas Widarsson". Can you please explain your example with some examples. Thanks.
In response to Comment 74: This is my php script "file-download.php": *********************************** <?php define('IN_SYSTEM',1); require "functions.php"; //various things including database connection. $BrowserIsGecko = (strpos($_SERVER['HTTP_USER_AGENT'],"Gecko")?1:0); $File = mysql_query_get_first_row("select distinct t1.*, t2.Txt as FileName from PermRead t3 left join Files t1 on t3.ItemID=t1.ItemID left join Items t2 on t1.ItemID=t2.ItemID where t3.ItemID='{$_GET['ID']}' and t3.UserID = '{$_SESSION['LoggedInID']}' and t2.IsFile=1"); if ($File !== false){ //************************************ //Note these rows, start //************************************ header("Content-Length: ".$File['Size']); header("Content-type: ".$File['MimeType']); header("Content-Disposition: attachment; filename=".($BrowserIsGecko ? str_replace(Array("Å","å","Ä","ä","Ö","ö"),Array("A","a","A","a","O","o"),$File ['FileName']) : $File['FileName'])); //************************************ //Note these rows, end //************************************ $Content = mysql_query("select Content from FileContent where FileID={$File ['ID']} order by ID"); if (mysql_num_rows($Content)){ while ($Row = mysql_fetch_row($Content)){ echo $Row[0]; } } }else{ echo 'Failure'; } ?> *********************************** The bug I am talking about relates to the header sending rows and the name of the file in the variable ´$File['FileName']´. When the filename contains a scandinavian character, Mozilla 1.4 Alpha (Build ID 2003040105) doesn't use the header supplied filename (in ´$File['FileName'] ´). The script name and the extension from ´$File['FileName']´ is used instead. Thus, the suggested save dialog file name is "file-download.php.doc" if ´$File ['FileName']´ is "Skräp1.doc". The suggested save dialog file name should in this case be "Skräp1.doc". I believe that is a bug since every non-mozilla browser mentioned in comment 72 behaves the expected way, which Mozilla does not. My workaround in this case is to replace all umlaut characters with alikes without any dots and rings. THAT is what is done if $BrowserIsGecko is true. Note regarding comment 73: Since the script file name overrides the "Content-Disposition:"-header when using mozilla, I decided to report my problem as a comment in this bug (#65827).
Errr, wait. You are sending these characters in an HTTP Header without any encoding? You just put these 8bit characters there? I don't think that's allowed.
File names CAN contain such characters. So I want to send such caracters. Is there any other way to do it, like specifying character set or something? Anyway. It works in all those other browsers. It can't be that all languages but english are unsupported. The .nu domain for example, can take DNS entries containing цед, or so I heard.
Not a bug; your Content-Disposition header is out of spec. Non us-ascii strings must use MIME parameter-value encoding. See RFC 2231
DNS names are something entirely different, and they use an ASCII encoding of the domain name (that's called IDN afaik)
*** Bug 207538 has been marked as a duplicate of this bug. ***
so, let´s take a deep breath :) Look at comment 35 and you will see that you can identify with yourself :) but I have found a solution, so that Mozilla/Netscape and Firebird are not attaching the script´s extension, yeahhh!!! I am so happy you cannot imagine :)... ok, just take: http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.php if you click on this url, the browser will attach the ".php" at the end of the ".mp3" and now add just some variable: (jea, just a var) http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.php?bla=bla if you click on this url, the browsers will NOT attach anything false, just the original extension. So, it´s a bug, but with my solution it is no problem anymore.
so, let´s take a deep breath :) Look at comment 35 and you will see that you can identify with yourself :) but I have found a solution, so that Mozilla/Netscape and Firebird are not attaching the script´s extension, yeahhh!!! I am so happy you cannot imagine :)... ok, just take: http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.php if you click on this url, the browser will attach the ".php" at the end of the ".mp3" and now add just some variable: (jea, just a var) http://manolito.image.ece.ntua.gr/~sivann/mozilla/down.php?bla=bla if you click on this url, the browsers will NOT attach anything false, just the original extension. So, it´s a bug, but with my solution it is no problem anymore.
oh, sry, my above post is double, because bugzilla returned nothing after 3 minutes, so I posted again, please @someone_who_can_do_this remove one of the double post and this post, too.
In addition to comment #81 you must always use the right mime-type. If you use a wrong mime-type, the browsers will attach the script´s extension again.
*** Bug 208291 has been marked as a duplicate of this bug. ***
In regards to comment #71 or #72, Netscape 7 still adds the script extension which in this case is ... php on BOTH urls with or without variables.
*** Bug 208381 has been marked as a duplicate of this bug. ***
*** Bug 204696 has been marked as a duplicate of this bug. ***
*** Bug 213100 has been marked as a duplicate of this bug. ***
Taking. I have a patch to fix the issue from comment 81, which is that the script's extension gets appended to the content-disposition filename if no parameters are present. That is, to my knowledge, what this bug is about now (it looks like it was about something else originally. oh well.)
Assignee: law → cbiesinger
Attached patch patch (obsolete) (deleted) — — Splinter Review
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: Future → mozilla1.6alpha
Comment on attachment 130544 [details] [diff] [review] patch this also fixes a bug where we would display a wrong mimetype for octet-stream content on windows
Attachment #130544 - Flags: review?(bz-vacation)
Comment on attachment 130544 [details] [diff] [review] patch > +//! What's with the exclamation points? I'd just use JavaDoc style comments here. > + if (!methodIsPost) { Why? Wouldn't we want to do this no matter what? > + if (pointPos != -1) { != kNotFound > + fileExtension = NS_ConvertUTF16toUTF8(ext); CopyUTF16toUTF8(ext, fileExtension); I'm not sure why the nsOSHelperAppService change affects anything. Could you explain that part?
Attachment #130544 - Flags: review?(bz-vacation) → review-
>> +//! >What's with the exclamation points? I'd just use JavaDoc style comments here. I don't know javadoc itself, it's a syntax that doxygen accepts at least. So I should use /**? >> + if (!methodIsPost) { >Why? Wouldn't we want to do this no matter what? Oh, indeed. Good point, I'll change that. >> + if (pointPos != -1) { >!= kNotFound will change >> + fileExtension = NS_ConvertUTF16toUTF8(ext); >CopyUTF16toUTF8(ext, fileExtension); will change >I'm not sure why the nsOSHelperAppService change affects anything. Could you >explain that part? Before, we would set aMIMEType to nsnull if it was octet-stream. This means that the content type was no longer available to this function, and therefore not set on the mimeinfo object. Instead, it would get whatever mimetype is associated with the extension. Now, this means that if the extension for an octet-stream file has a mime type, that type will be the one that the mimeinfo object will get. Which means that the helper app dialog will show a wrong mime type. With my change, we just ignore the octet-stream type for looking up an extension from it, but keep it around to set it as the type on the mimeinfo. (While this is not strictly related to this bug, I noticed it when fixing this.)
Yes, use /** Thanks for the explanation on the Windows change. Makes perfect sense now. You may want to change or remove the last sentence of the comment there, though.
Attached patch patch v2 (deleted) — — Splinter Review
Attachment #130544 - Attachment is obsolete: true
Attachment #130681 - Flags: review?(bz-vacation)
Comment on attachment 130681 [details] [diff] [review] patch v2 Looks good.
Attachment #130681 - Flags: review?(bz-vacation) → review+
Attachment #130681 - Flags: superreview?(darin)
Comment on attachment 130681 [details] [diff] [review] patch v2 >Index: nsExternalHelperAppService.cpp >+/** Gets the content-disposition header from a channel, using nsIHTTPChannel nit: nsIHttpChannel >+ if ( httpChannel ) >+ { >+ httpChannel->GetResponseHeader(NS_LITERAL_CSTRING("content-disposition"), aDisposition); >+ } >+ if (aDisposition.IsEmpty()) nit: eliminate whitespace around "httpChannel" to be consistent. >+ * @param aURI Optional. Will be used to get a fallback charset for the >+ * filename, if it is QI'able to nsIURL >+ * @param aMIMEHeaderParam Optional. Pointer to a nsIMIMEHeaderParam class, so >+ * that it doesn't need to be fetched by this function. nit: shift "filename, if it..." to the left to line things up. >+ const nsAString & ext = Substring(filename, pointPos + 1, filename.Length() - pointPos); hmm... don't you mean: const nsAString & ext = Substring(filename, pointPos + 1, filename.Length() - pointPos - 1); sr=darin with these small fixes.
Attachment #130681 - Flags: superreview?(darin) → superreview+
No longer blocks: 217509
Blocks: 218595
I don't think I want that - 1... consider this example: filename="x.abc" pointPos will be 1, then; and .Length() will be 4 so Length() - pointPos is 3, and that is exactly the substring length that I want.
Checking in win/nsOSHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/win/nsOSHelperAppService.cpp,v <-- nsOSH elperAppService.cpp new revision: 1.43; previous revision: 1.42 done Checking in nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsE xternalHelperAppService.cpp new revision: 1.211; previous revision: 1.210 done
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
> pointPos will be 1, then; and .Length() will be 4 .Length() of "a.bcd" is 5, not 4. Consider a filename starting with '.'. Then pointPos is 0, and you would be getting a string of the same length as the filename, whereas you want one char less. As in, I think you do need the -1.
hmm, you are right. seems I was not able to count. So I checked in a fix for that, added the -1. to my defense, this code was copied from nsObjectFrame.cpp: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsObjectFrame.cpp#517 which has the same off-by-one problem, I'll file a new bug for that
actually that was not true it uses iLastCharoffset, which is Length() - 1 so I jsut c&p'd wrongly
*** Bug 221802 has been marked as a duplicate of this bug. ***
In PHP, we are sending a timestamp variable to the script that does the downloading and the browser treats the file name correctly.
that should no longer be ncessary, this bug is fixed.
*** Bug 223980 has been marked as a duplicate of this bug. ***
*** Bug 224656 has been marked as a duplicate of this bug. ***
*** Bug 225331 has been marked as a duplicate of this bug. ***
*** Bug 199832 has been marked as a duplicate of this bug. ***
Alias: content-disposition
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: