263876 - File Download URL truncated after plus "+" symbol

Status: RESOLVED INVALID

(Toolkit :: Downloads API, defect)

Description

[Chris Messina]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

In my case another oddity occurred which I will post as a separate bug. I was
trying to download two different files with different URLs, but apparently,
because of a '+' symbol in the URL, everything after the symbol was truncated
and the second file overwrote the first. The URLs in question:

https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5007/FFox+RGB.tif
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5009/FFox+Grid.ai

Interestingly this file:
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5008/FFox+CMYK.tif
was "correctly" renamed to ffox-1 (no extension). 


Reproducible: Didn't try
Steps to Reproduce:
1. Download
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5007/FFox+RGB.tif
2. Then download
https://secure2.silverorange.com/intranet3/so/fileloader.php?attachment=5009/FFox+Grid.ai
concurrently

Actual Results:  
The first file is named ffox (no extension). The second file downloads OVER the
first file and is named also ffox. The third file downloads "correctly" and has
a "-1" appended to the filename, even though it's not the correct filename.

Expected Results:  
Each file should have downloaded separately and maintained its original name.

Contact Steven Garrity ([e-mail]) for information about
accessing the protected extranet.

Comment 1

[Stefan Baebler]

We are facing same problem on our application.
I've tried replacing pluses (+) with hex escaping (%20), with same result.

This makes me think that the issue might be related to wrongly set Content-
Disposition header of the response (generated programatically by the download 
script).

Question: what is proper Content-Disposition header for a file with spaces in 
tis name?

It might also be that firefox is misinterpreting that header (with IE it works 
just fine)

One needs to test what happens if you try downloading a file with spaces in the 
filename from a regular server, eg plain apache.
There is probably no content-disposition header sent, and firefox deducts the 
filename from the URL.

Comment 2

[Stefan Baebler]

For me it worked to use quotes around the filename in conthe Content-
Disposition header, like this:

Content-Disposition: attachment; filename="a file with spaces in the name.txt"

no other changes were required.

Suggesting new bug summary: 
   Content-Disposition header - unquoted filename cut at first space

or to close the bug if someone can point me to HTTP spec, sayin that using 
quotes is mandatory if filename contains spaces.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Content-Disposition is not part of the HTTP spec, but part of the MIME spec. 
The quotes are in fact mandatory if there are spaces (or any  of a variety of
other characters) in the filename.