User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 I created a file download tool with PHP. I add the code which generates the download file: -----<snip> $size = filesize( $file ); $ct = getContentType( $file ); // function returns appropiate content type header("Content-Type: ".$ct); header("Content-Disposition: attachment; filename=".basename($file)); header("Content-Length: " . $size); header("Content-Transfer-Encoding: binary"); readfile($file); -----</snip> If the download file contains spaces Mozilla cuts the filename at the first space. Mozilla on Linux does this right. It evens saves the file with spaces properly. Reproducible: Always Steps to Reproduce: Sorry, the download area ist protected by password for my company, so this ist not very useful 1. click on download link, so the download script gets activated. This sends the file like described above. 2. Mozilla pops up the dialog, where it asks what to to with the file. At this point it just has the filename that was cut at the first space. Actual Results: file saved with wrong filename Expected Results: accept filename with spaces

Just two days ago I was talking about this issue in #mozillazine with Christian Biesinger and Boris Zbarsky, and they said that this is the proper behaviour according to the RFC. The solution it's just to put the quoted filename and then everything will work fine as that is the expected syntax. So that part is invalid, but different behaviour in Linux doesn't seem right to me. Biesi said that he was seeing this difference although in the end it seemed to be due to the build. Moving to File handling and CC Boris and Biesi so they can say if this is valid or not.

jshin, could we reasonbly include spaces in the filenames here? I'm not sure how this would affect mailnews, if at all....

As I mentioned the Linux build where Mozilla acts as expected, I supply the Build Identifier and additional information: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021205 Debian/1.2.1-0 from (/etc/apt/sources.list) deb http://people.debian.org/~frankie/debian/woody/kalem/ / $ apt-cache show mozilla-browser Package: mozilla-browser Version: 2:1.2.1-0 Priority: optional Section: web Maintainer: Takuo KITAME <kitame@debian.org> [...] Architecture: i386 Filename: ./mozilla-browser_1.2.1-0_i386.deb

That linux build is too old, current ones should behave just like in windows.

Alfonso, the POINT is that the behavior on both may need changing. In case you're curious, Windows builds of 1.4 behave just like Linux ones, and neither behaves like today's build. The question is whether the change in behavior is desired or not (it was an unintended byproduct of another change).

There's no difference in behavior across platforms. The change I made was XP(cross platform). Now for the problem reported, I would stick to the current behavior. There's no clean way to get Mozilla to be more generous. I have to introduce a very dirty code, which I wouldn't. PHP code in comment #0 is incorrect in two counts. One is not quoting 'space' and the other is not using RFC 2231-encoding (for non-ASCII characters). I know there are a lot of server-side codes like that. Against the latter violation(not using RFC-2231 encoding), we have some protection, but for the former, as I wrote, Mozilla wouldn't change the behavior.

OK. If jshin says the header parser can't reasonbly deal with spaces here without breaking pages doing the right thing, then wontfix.

After reading a bunch of drafts on HTTP and several RFCs I changed my code: ------<snip> $size = filesize( $file ); $ct = getContentType( $file ); /* * Content Disposition according to RFC 1806 * Filenames in ASCII according RFC 1521 * encoding according RFC 1522 - MIME (Multipurpose Internet Mail * Extensions) Part Two: Message Header Extensions for Non-ASCII Text */ $BrowserIsGecko = (strpos($_SERVER['HTTP_USER_AGENT'],"Gecko")?1:0); if ( $BrowserIsGecko ) { $disp_file = "=?iso-8859-1?Q?" . str_replace( /* TODO: add rest of the special chars */ array(" ","Ä","ü"), array("=20","=C4","=FC"), basename($file) ) . "?="; } else { $disp_file = basename( $file ); } header( "Content-Type: " . $ct ); header( "Content-Disposition: attachment; filename=" . $disp_file ); header( "Content-Length: " . $size ); header( "Content-Transfer-Encoding: binary" ); readfile( $file ); ------</snip> This works on Mozilla on Windows, but not under Linux (ok, 1.2.1)

Christoph, Mozilla does not handle the non-ascii syntax up through 1.4. That part is new in 1.5.

You should have read more updated RFCs. Didn't I say that you should encode it per RFC 2231? Specifically, you should not use RFC 2047-style (RFC 1522 was obsoleted by RFC 2047 several years ago !) encoding. As you found out, Mozilla is generous and accepts RFC 2047-style encoding, but that doesn't mean that you can get away with violating the standard.

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

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

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

I hesitate to say this, as I mean no disrespect to anyone...but history has shown that sticking to the letter of the law (or of the RFC) in every case yields a fully standards-compliant browser that fails to work properly with several real-world situations. Obviously we don't want people to take advantage of "relaxed standards", but the reality is that a lot of code out there which doesn't properly quote the file name is going to be hard to get fixed. Again, with full respect for your technical position, failure to make certain exceptions like this will mean that all most users will see is that MSIE/Opera/Netscape 4.x all work fine and Mozilla/Netscape 7.x do not.

vrfy WONTFIX.

Thomas, see comment 6. We _used_ to break the RFC just like IE does and you want us to. Then we implemented full support for internationalized filenames (which IE does not have, last I checked). Doing this, is not really compatible with breaking the RFC in this way (ambiguous situations arise where it's really impossible to tell what the filename is). So we have decided to go with making two out of three (international filenames, correct pages, incorrect pages with non-international filenames) work.

putting testcase in url field. Server sends "a b" (without quotes) as filename.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I know what the RFC dictates. But I really think you should reconsider (and then do it again). This bug is annoying as hell, especially when you get mail via Outlook web (which quite a few does). So what's wrong with bending the RFC and give a lot of users a better browsing experience?

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

100% agree with Morten Primdahl (Comment #32) - the bug is annoying as hell. Issue is being discussed more then a year (lodged in Oct 2003) with no progress! I lodged today bug #273520 on the same issue in Firefox, sorry didn't find #221028. My bug has been "resolved" in 10 minutes with reference to the 221028. Comments #18-32 are all about the same, and all are "resolved" as well with reference to 221028. Looks like we are asking for something impossible looking at "WONTFIX" resolution.

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

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

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

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

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

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

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

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

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

This is more than an annoyance. If Firefox is to take market share from IE (as it should) these types of issues should be reconsidered. The average user isn't going to understand why there are differences between how IE and Firefox download files. IE is going to be the benchmark (rightly or wrongly so) - can this be reconsidered?

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

Great... so when is the update for this BUG going to be released? Or does Mozilla expect every single website in the world to put quotes around the filenames as a solution to the problem with FireFox? :rolleyes:

(In reply to comment #46) > Great... so when is the update for this BUG going to be released? this bug is resolved as wontfix. > Or does > Mozilla expect every single website in the world to put quotes around the > filenames as a solution to the problem with FireFox? :rolleyes: right.

(In reply to comment #47) > (In reply to comment #46) > > Great... so when is the update for this BUG going to be released? > > this bug is resolved as wontfix. > > > Or does > > Mozilla expect every single website in the world to put quotes around the > > filenames as a solution to the problem with FireFox? :rolleyes: > > right. Why is it that this issue cannot be fixed? Politics? If Joe Blow downloads a file which suddenly has no type (due to missing filename extension) that file is unusable by him making Moz/FF look bad. How big a deal is it to bend an RFC to realize a quick win like this?

(In reply to comment #48) > How big a deal is it to bend an RFC to realize a quick win like this? Please *read* the bug before making comments like this. In particular, read comment 6 and comment 16. Bugzilla is not a discussion forum. This bug has been verified as wontfix, and no amount of commenting here is going to change that.

This <if it is not a bug, I don't know what to call it> is, as many people have pointed out, extremely annoying. I have read all of the comments below, so I am not going to ask for a fix, but how about a workaround... If Firefox finds a file to download that does not have an extension, then it offers a text box (in the pop-up that appears anyway) that offers the user a chance to rename it. In fact, this box could be there always, and normally populated with the name of the file about to be downloaded/opened. A rename (before downloading) option would be useful on occasion since several downloads need to be renamed as the sites I get them from are unimaginative about file naming.

file UI issues elsewhere, maybe in a new bug

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

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

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

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

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

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

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

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

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

I found that passing a filename with spaces in the http header to firefox browser produces the same error (when downloading files). However, I found that a fix was putting extra quotes around the filename: Produces the bug: $file = 'Image Name.jpg'; Fix: $file = '"Image Name.jpg"'; Hence, add extra " quotes around the $file variable (part of the string variable) and problem should be solved! Ok, honestly I only started learning PHP today (I usually do JScript ASP), but seems like it should do the job (and I don't think this method complicates that RFC issue that spawned the WONTFIX status?) If I'm not mistaken, here is a fix: header("Content-Disposition: attachment; filename=\"".basename($file)."\"");

yes, that is the correct fix. it's what the RFC says to do.

These guys might as well add that invalid html tags yeild undesired results and that it should be corrected in the next Firefox. This is the most fruitless bug report I've ever stumbled upon.

Clarifying this bug, and a new fix suggestion on firefox's part: ---------------------------------------------------------------- The problem is not with HTML tags (something like "<A HREF=this is a test.jpg>" should expectedly yield undesired results, but that is not the issue here), it is with regards to custom headers sent to the browser. A user sends the following: $file = "this is a test.jpg"; header("Content-Disposition: attachment; filename=".basename($file)); The filename is interpreted by firefox without quotes (as the resulting string doesn't contain quotes around the filename), hence the effective resultant filename is "test", and the extension is lost. So the problem is on the side of the person programming the script on his/her website. However, many people have made this mistake on their websites - and netscape, internet explorer and opera automatically account for this user error, but firefox doesn't. This means that webmasters that don't test this in firefox will not know that their firefox users don't get the correct filenames, which is where the problem comes in. Firefox should evaluate the full header string for this logical error before executing it (searching to see if text after "filename=" is already enclosed in quotes, and if not, adding quotes around the filename specified) - is that not a simple fix on firefox's side? This is actually a commonly encountered issue and the fix is probably as simple as that (?) yet has been overlooked??? Apparently this bug is also present in Outlook Web Access where attachment filenames are truncated in the same manner - as far as my understanding goes, that aspect is a bug within Outlook Web Access (which I assume uses the same file handling engine within firefox) that should be looked into. I'm no expert in firefox source code, so I'm not selecting to reopen the bug myself, but if anyone feels I've stumbled upon something, please take the initiative to do so on my behalf, thanx!

(In reply to comment #64) > is that not a simple fix on firefox's side? It's not. > This is actually a commonly > encountered issue and the fix is probably as simple as that (?) yet has been > overlooked??? No, it hasn't. See comment #6.

In response to comment #16, could the code err on the side of tolerating spaces, except in the ambiguous cases, where it should err on the side of proper international character support? Is this situation analogous to quirks mode? Could we make it a user-selectable option with a reasonable default?

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

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

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

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

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

(In reply to comment #15) > vrfy WONTFIX. > as bz@glcstudios.com in comment 61 THERE IS a fix for this problem, because the bug is not in the browser but in the page. I think you should be more clear about this. I´m a begginer programmer in the php language and I was googling about this and I found the following page http://www.extensionsmirror.nl/index.php?showtopic=4822 as the best result but I was angry when I read "See Bug 221028 for more information and the reason why this behavior is not going to be changed in Firefox." there is a lot of confusion in this bug discussion and before I read until the final of the page I thought that it couldn´t be resolved. so I suggest you to change the status of the bug and put the following code as the resolution: header("Content-Disposition: attachment; filename=\"".basename($file)."\""); as bz@glcstudios.com in comment 61 said. I´d like to remember that it MUST BE DOUBLE QUOTES. I´ve read about this solution(putting quotes around the filename) but I tested with a single(or simple) quote, and it didn´t work. Congratulations for the mozilla comunnity for making a so cool, functional, fast and marvelous brouwser: firefox.

I used this code to get around it.. header("Content-Disposition: attachment; filename=\"".$filename_name_with_spaces.".".$filename_ext."\"");

that's the correct fix, indeed. (unless the filename contains a quote sign...)

Curiously enough, drag-and-drop is not impacted. Compare for instance on page http://bp2.blogger.com/_1bKnHq3a-W8/SI-QLCbh5bI/AAAAAAAABFk/8KWq_R_lC8Y/s1600-h/Picture+6.png : - Right click > Save as => filename proposition is "Picture.png" - Drag-and-drop to the desktop or a folder opened in Nautilus (Gnome) => file is saved as "Picture+6.png". How can we explain such different behaviours?

Could you please reopen this bug? A space is part of ASCII and clearly an allowed character, RFC 2231 also explicitely allows linear white space. The choice not to accept a value containing a linear white space is a violation of that RFC and leads to stupid situations like the one I just encountered - being sent an email containing several attachmants, each with the same prefix followed by a space character.

> A space is part of ASCII and clearly an allowed character, RFC 2231 also explicitely > allows linear white space. RFC 2231 says: parameter := regular-parameter / extended-parameter If you're using "content-disposition=foo bar" that does not match the extended-parameter production for the parameter name. The regular-parameter production is: regular-parameter := regular-parameter-name "=" value where 'value' is defined in RFC 2045 as: value := token / quoted-string token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials> So spaces are explicitly excluded from the production. Can you please point to the part of RFC 2231 that made you think that spaces are "clearly an allowed character" here? I'm also not sure what you mean about linear whitespace; the only mention of linear whitespace in RFC 2231 is in the context of non-normative discussion about allowing line-wrapping by doing extended parameters (the reason RFC 2231 exists).

Argl. It's always nice to make an idiot out of oneself in public. I take everything back and be off to complain to gmail :)

(In reply to Boris Zbarsky (:bz) from comment #88) > ... +1 (except for RFC 2231 been obsoleted by RFC 5987 for use in HTTP header fields, but that doesn't affect the correctness of what you said)

Team, Is there a plan to address this issue in near future ? regards, Pravash

There are extensions that enable end users to work around this problem if sites still do this: Mine: https://addons.mozilla.org/firefox/addon/content-type-fixer/ Another option: https://addons.mozilla.org/firefox/addon/fixdisposition/