210147 - filename with spaces shown in the save dialog is different from the one specified in the Content-disposition header

Status: RESOLVED DUPLICATE of bug 221028

(Core :: Disability Access APIs, defect)

Description

[Spiros Ioannou]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030618
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030618

In recent builds (Gecko/20030618) when clicking on a link where a
"Content-disposition: attachment; filename=xyz" is used, if the filename has
spaces, only the first non-space part of the filename is displayed in the save
dialog.
Strangely enough, if shift-click is pressed, the filename is displayed correctly.


Reproducible: Always

Steps to Reproduce:
1. click on the "here" part of the url 

Actual Results:  
Filename shown in the save dialog was "300Kmh"

Expected Results:  
filename should be "300Kmh on bike.mpg"

Comment 1

[Matthias Versen [:Matti]]

-> File handling

Comment 2

[Boris Zbarsky [:bzbarsky]]

If your filename contains spaces, you need to quote it.  The definition of a
filename token in that header is either 1) a quoted string or 2) a string of
characters with no whitespace.

The shift-click filename parsing is buggy (not to mention that it does not
properly handle non-ascii stuff -- jshin, would you mind looking into that?  The
code is in contentAreaUtils.js; the functions are |get suggestedFileName()| and
|onStopRequest|).

Comment 3

[Spiros Ioannou]

It seems you are right, but it worked before, and it worked with NS4 and IE so
maybe it should have the same error-forgiving behaviour with those?


rfc2183 
filename-parm := "filename" "=" value
...
rfc2045
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>

Comment 4

[Jungshik Shin]

I'm sorry I got here late.

Boris, thank you for alerting me to this. 
The issue you mentioned is taken care of in bug 158006. I've got a patch and
have been waiting for landing of the patch for bug 162765 and jag's sr.

Spiros,
I'm sorry, but I'm afraid that you're asking for too much generosity. I believe
in a famous net maxim 'be generous in what you accept and strictly abide by the
standard in what you emit to the wild'. However, using space(s) without quote in
filename parameter is too great a sin to be forgiven. In addition, it's all but
impossible to be generous in the case at hand while still sticking to the standard.

Which would you choose, if you have to, between Greek filenames properly decoded
and handled (both in ISO-8859-7 and UTF-8) and 'broken' unquoted filename with
space?  

NS 4 and MS IE __appear_ to be forgiving not because they're generous but
because they didn't implement RFC 2231 and 2184 properly. 

Marking as 'invalid'.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Verified.  If allowing spaces would mean that we don't properly handle
non-English filenames, then that's not acceptable.

Comment 6

[Norbert]

Although if you see this as server problem:
All other Browsers and good Download-managers like NetAnts or FlashGet do
extract such names withn spaces correctly from the content-dispositio header.

So please change this.

Comment 7

[Jungshik Shin]

(In reply to comment #6)
> Although if you see this as server problem:

  It IS !!!

> All other Browsers and good Download-managers like NetAnts or FlashGet do

They're not good download managers but bad download managers that get in the way
of  promoting standard compliance. 

Comment 8

[Boris Zbarsky [:bzbarsky]]

Norbert, read comment 5 please. I know for a fact that IE screws up non-English
filenames badly (unless they just happen to be in the default codepage of the
windows install, which is rather limiting).

Also, drive-by commenting (without ccing yourself to get the replies) is VERY rude.

Comment 9

[Norbert]

Maybe, if asiayeah-gnutella-search-engine is the only "server" that does not
include quotes in the content-disposition header and changing it would lead to
other problems, you can keep it as is.

I see your point that here quotes would be necessary.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Argh, sorry for the spam.

*** This bug has been marked as a duplicate of 221028 ***