Files handler bug with filenames containing a space

[DarTar]

Files handler: if the filename contains a space, Moz/FF will show only the first word in the download dialog; filename should be enclosed in quotes.

Thanks to MrTrick for pointing out this problem It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space. Two possible solutions:

1. Prevent that file names are stored with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS or the user's OS as to whether spaces in file names are valid.
2. Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - provided both the server OS and the downloading user's OS can handle such file names.

Take your pick ;-) -- JavaWoman

Related tickets

#72 #89

[DarTar]

moving to 1.1.6.3 for speeding up the release of 1.1.6.2

[BrianKoontz]

The problem with urlencode() is that it embeds a '+' symbol, which is a perfectly legitimate character in a filename. urldecode() doesn't know whether the '+' symbol is a real '+' or just a space. So I've attached a patch that saves the file using rawurlencode(), replacing ws with %20, wraps the Content-Disposition filename in quotes so Mozilla and family can figure out what to do with it, and makes sure the file displays with the original ws. It shouldn't really matter to the user what the stored filename looks like.

I've tested with filenames with embedded ws and embedded + symbols; uploads, deletions, and downloads all work as expected.

[BrianKoontz]

Patch that permits embedded ws and other special chars in filenames

[BrianKoontz]

Closed in [257]. Properly encoded/decodes embedded non-alphanum characters in filenames.

[DarTar]

Retargeting to 1.3, this ticket has already been closed in trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

[BrianKoontz]

Updated milestone to 1.3.1