222438 - Problem downloading files with spaces in name

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Tim Meader]

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

There is an problem whenever you download a file in any browser based on 1.5
engine (thus Mozilla and Firebird). When you are clicking on a link to a file
that has %20's for spaces in the name, when the resulting save dialog comes up
it truncates that filename down to on the first part up to the first space.
Example: if you click on a link to a file called "New Text Document.txt" (ie -
the html for this would be <a href="http://New%20Text%20Document.txt">New Text
Document.txt</a>) the dialog that pops up will ask to save it as the filename
"New.txt".

Reproducible: Always

Steps to Reproduce:
1.Create a test page.
2.Create a test file "New Text Document.txt" on your harddrive.
3.In your test webpage, link the file as described (with %20's for spaces)
4.Click on the link to try to download.

Actual Results:  
The filename proposed for saving will be truncated as described above.

Expected Results:  
Should use the entire filename for proposed filename.

Comment 1

[Boris Zbarsky [:bzbarsky]]

clicking on a link to a .txt file will typically show the file, not prompt to
download... so I'm not sure which part of your steps to reproduce is wrong --
the filename, the way you click, or what.

Comment 2

[Tim Meader]

Apologies... ".txt" was a bad example. Change it to whatever you like. ".exe"
for example. Then repeat the same steps.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  Named a file "foo bar.exe".  Created a file with <a
href="foo%20bar.exe">test</a> in it.  Clicked.  Chose "save as".  The filename
in the filepicker was "foo bar.exe".  So I can't reproduce this problem with a
current build...

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

so does this happen with local files, as the text in comment 0 suggests, or with
files from http, as the example link indicates?

Comment 5

[Jijoe Vurghese]

I have this problem with Firebird 0.6, 0.6.1 and 0.7 release builds. This
truncation of filename doesnt happen with Mozilla 1.4, 1.4.1 (I havent tried 1.5
yet cos Firebird is my default browser :-) )

Anyway, I can reproduce this whenever I click on an HREF link (on a website)
with names like: 

How do you do.doc.

The dialog that Firebird brings up shows as filename:

How

Additionally, since Firebird cannot seem to figure out the file type, the only
option I get when I click is a download dialog with "Save to Disk" checked.

With the same scenario on Mozilla 1.4.1 and 1.4, the download dialog shows
filename as: 

How do you do.doc

Comment 6

[Tim Meader]

Apologies again. I could've sworn that I'd tested this on a local file... but I
guess I did not. My test case was based on a file on my personal webserver. So
yes, it is downloading through http (or https) when this error happens. It is
exactly as Comment #5 described.

Comment 7

[Tim Meader]

I can vouch for all the browsers in Comment #5, as well as Mozilla 1.5 (the
final release). I can also add that I just tested it with Mozilla 1.5 Final on
OSX 10.2.8.... same problem.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I just set up a testcase for this at
http://web.mit.edu/bzbarsky/www/testcases/filehandling/testSpace.html

Click on the link, get the helper app dialog, select "save".  The suggested
filename I get is "foo bar.exe".  Is that what you are seeing, or are you seeing
"foo.exe"?  If you're seeing "foo bar.exe", I would like to know how the case
you are testing differs from this one.  Are you sending Content-Disposition
headers, for example?

Further, please don't bother testing with firebird, which is in the process of
forking this code, for this bug.  If there is a firebird problem, file a
firebird bug.

Comment 9

[Jijoe Vurghese]

I have to tweak my comment #5 a little....

When a website has an HREF pointing to a file How do you do.doc, unless the HREF
is quoted as <A HREF="How do you do.doc"> or escaped as <A
HREF=How%20do%20you%20do.doc>, the webserver would return an error when this
link is clicked.

So when I just retested again, neither Firebird 0.7 nor Mozilla 1.5 have a
problem  with the download dialog box. They both identify the full file name and
apt file type.

The issue I really encountered (and just reproduced) is when a dynamically
generated file (say, the document retrieval system hits a backend appserver to
retrieve a file based on a form button click) is streamed back to the browser,
and the filename has a space in it.

In that case, both Mozilla 1.5 and Firebird 0.7 exhibit the behavior I described
in comment #5.

IE 6 on the other hand correctly displays a download dialog with the complete
filename and type. 

My guess is that the appserver (actually a vendor product) is not quoting or
escaping the filename and hence, both Firebird and Mozilla barf on the filename
and subsequently the file type leading to the download dialog behavior I saw.

So to recap - static HREF links with filename spaces - I dont seem to have an
issue opening. dynamically generated files (mime type -
application/octet-stream) with spaces in filename - cannot open correctly.

Comment 10

[Jijoe Vurghese]

Some more info to help troubleshoot. I got a network trace going between my
browser and this appserver. It seems to conrim my suspicion. The
Content-Disposition header in the server response to browser is a filename with
spaces but not quoted.

>>>>> Start request >>>>>>

GET /Billing/doccontent.dll?LibraryName=LIBSYS1^PANAGONSL03&SystemType=2 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; SBC)
Host: panagonff04.sbc.com
Connection: Keep-Alive
Cookie: ASPSESSIONIDGQGGHFNQ=BONLKBBCKKKMGDHPEDJDHPFP
<<<<< End Request <<<<<<

>>>>>> Start Response >>>>>

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Fri, 17 Oct 2003 17:28:24 GMT
HTTP/1.1 200 OK
Set-Cookie: path=/idmws
Content-Type: application/octet-stream
Content-disposition: filename=CCRB Log.100903.xls
Content-length: 511488

<<< I truncated the rest of response - it was the actual file contents <<<<

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yeah, the behavior for content-disposition headers changed, and purposefully. 
It's not changing back.  All that remains to be seen is whether that's the
problem Tim is having or whether he's running into something else.

Comment 12

[Jijoe Vurghese]

Per comment #11, does it mean that Mozilla 1.5 will not "respect" an unquoted
filename param in the Content Disposition header, if it has spaces? I was
looking through the HTTP standard definition for this header and it looks like a
filename value can be expressed as a quoted string or not. 

I'm trying to understand the rationale behind this permanent behavior change.

Also, if the filename value was quoted by the server, would this download dialog
have worked? If so, I can try hitting up the vendor to fix their product to
comply with the standard... 

Comment 13

[Boris Zbarsky [:bzbarsky]]

> it looks like a filename value can be expressed as a quoted string or not. 

Yes, but unquoted strings are only allowed to contain certain chars there, and
spaces are not in that list.

> I'm trying to understand the rationale behind this permanent behavior change.

The rationale was the addition of support for non-ascii filenames in this
header.  Supporting non-ascii filenames (via the correct encoding indicators)
and also supporting broken servers that don't quote filenames containing spaces
proved pretty much impossible; we chose to go with making sites that are doing
the right thing work and making non-ascii filenames possible.

> Also, if the filename value was quoted by the server, would this download
> dialog

Yes, of course.
have worked?

Comment 14

[Jijoe Vurghese]

Thanks for the info - time to go beat up my vendor :-)

Comment 15

[Tim Meader]

I've confirmed that, yes, that was the problem. One of my main test beds was a
mod_perl driven server I use that acts as a file upload/download repository. I
was using the Content-Disposition header to force downloading no matter the file
type. After adding the quotes around the filename all is well. Thanks for
everyone's help. And just so anyone else using IMP (freeware web-based mail app)
knows, it also appears to not quote the filename in their headers. I'm gonna go
patch that now and try to get it into their stable branch. Thanks again.