Closed Bug 221028 Opened 21 years ago Closed 21 years ago

content-disposition filename cut (truncated) at space

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: c.loeffler, Unassigned)

References

()

Details

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.
Assignee: blake → file.handling
Component: Download Manager → File Handling
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).
OS: Windows 2000 → All
Hardware: PC → All
Summary: cuts filename at space → content-disposition filename cut at space
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=application%2Foctet-stream&disposition=inline&filename=a+b
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.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
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.
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=application%2Foctet-stream&disposition=inline&filename=a+b
*** 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. ***
Summary: content-disposition filename cut at space → content-disposition filename cut (truncated) at space
*** 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)
Product: Core → Core Graveyard
Team,

Is there a plan to address this issue in near future ?

regards,
Pravash
See Also: → 1380035
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/

FWIW, after other browsers indicated they were not going to make their parsing more strict, we changed our parsing in bug 1440677. Firefox versions 81 and later will no longer truncate Content-Disposition filenames at spaces when unquoted.

Resolution: WONTFIX → WORKSFORME
You need to log in before you can comment on or make changes to this bug.