View Issue Details

IDProjectCategoryView StatusLast Update
0009775mantisbtupgradepublic2010-02-22 14:35
Reporterllattan Assigned Todhx  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformx86_64OSRedHat Enterprise LinuxOS Version5.2
Product Version1.1.4 
Fixed in Version1.2.0 
Summary0009775: Unable to download attachments with spaces in the filename
Description

I have mantis 1.0.7 on RHEL 5.2 x86_64.
After upgrade to 1.1.2, I can´t download issue attachments with spaces in filenames.

For example:

Mantis 1.0.7 on RHEL 5.2 x86_64
http://10.20.6.10/file_download.php?file_id=445&type=bug [^]
TABLERO DE CONTROL AVANCE DE COMPRESOR.xls

Same machine, after upgrade:

Mantis 1.1.4 on RHEL 5.2 x86_64
http://10.20.6.10/file_download.php?file_id=445&type=bug [^]
TABLERO+DE+CONTROL+AVANCE+DE+COMPRESOR.xls

The filename in issue appears right.
When I try to download the file, the spaces change to "+"
and I can´t download the attachment.

Is this a bug ?
How can I solve the problem ?

Thanks in advance.
Leandro.

Steps To Reproduce

I did the upgrade procedure.

TagsNo tags attached.

Relationships

has duplicate 0009464 closedvboctor Broken attachments links after upgrade 
related to 0010402 closeddhx Can't download attachments with IE 

Activities

vboctor

vboctor

2008-11-08 13:41

manager   ~0019816

I was unable to reproduce this problem. The fact that spaces are replaced by + signs is reproducible. However, I'm able to download attachments with spaces whether they are stored in DATABASE or DISK.

vboctor

vboctor

2008-11-14 01:53

manager   ~0019881

No longer targetting 1.1.5.

llattan

llattan

2008-11-21 17:14

reporter   ~0019977

Think ... if I upload the file to mantisbt, and then I download the file from mantsibt ... the filename changes.

When the solution will be targetted ? In which version ?

Regards.
Leandro.

llattan

llattan

2008-12-29 08:08

reporter   ~0020495

When the solution will be targetted ? In which version ?

Regards.
Leandro.

llattan

llattan

2009-02-02 15:57

reporter   ~0020768

Think ... if I upload the file to mantisbt, and then I download the file from mantsibt ... the filename changes !!!

When the solution will be targetted ? In which version ?

Regards.
Leandro.

caldarola

caldarola

2009-02-04 03:17

reporter   ~0020780

This is one of serious issue because I'm still using the 1.1.0 version.

llattan

llattan

2009-02-25 16:27

reporter   ~0020942

This is one of serious issue because I'm still using the 1.0.7 version, and I can´t do an upgrade.

I need a solution.

Regards.
Leandro.

llattan

llattan

2009-03-12 20:29

reporter   ~0021038

This is one of serious issue because I'm still using the 1.0.7 version, and I can´t do an upgrade.

I need a solution.

Regards.
Leandro.

llattan

llattan

2009-03-31 17:09

reporter   ~0021346

Could anybody help me ?

caldarola

caldarola

2009-04-01 03:12

reporter   ~0021348

llattan, I think you could sponsor this issue if it is very important for your work, do not forget Mantis is a open source project.

llattan

llattan

2009-04-20 10:48

reporter   ~0021604

I know that Mantis is a open source project.
I'm very glad to say that we've used version 1.0.7 for 2 years without problems.

We want to upgrade to latest release, but only this issue doesn't allow to do the upgrade.

I wonder if it could be targetted in next release.

Thanks in advance.
Leandro.

llattan

llattan

2009-07-14 18:16

reporter   ~0022497

I wonder if I upgrade my system from version 1.0.7 to version 1.2.0 the problem will be fixed.

dhx

dhx

2009-07-14 22:14

reporter   ~0022501

Last edited: 2009-07-14 22:16

Yes, version 1.2.x fixed this problem (and many more) relating to the names of attachments. I am storing attachments in the database.

I'm going to close this issue as resolved but would first like to hear some confirmation that the issue is also fixed for attachments stored on disk (and not in the database).

Supp

Supp

2009-07-20 16:45

reporter   ~0022535

Hi,
I'm storing files on disk (not in DB), using 1.2.0rc1 (with diff from 0010494 because we're using Czech and filenames were mangled) and when downloading files all spaces are replaced with '+' signs.

Config: PHP 5.2.9-pl2-gentoo with Suhosin-Patch 0.9.7 (Gentoo), apache 2.2.1 (running on PPC32 Gentoo).

llattan

llattan

2009-07-20 16:53

reporter   ~0022536

I'm storing files on DB (Mantis 1.0.7 on RHEL 5.2 x86_64) and the problem is the same.
When I download files all spaces are replaced with '+' signs.

Wouter

Wouter

2009-07-21 02:37

reporter   ~0022538

I am using Mantis 1.1.18 and storing files on disk. All spaces are replaced with + signs. It's very annoying, plus it alters files without permission which i find a grave matter. If there's any solution to this (workaround, patch anything) I'd like to know. Running Mantis in a production environment.

dhx

dhx

2009-07-21 06:41

reporter   ~0022539

As stated before, can someone reproduce this bug with the latest 1.2.x or 1.3.x version checked out from the git repository? The versions of MantisBT I see being tested here most likely do not contain all the required UTF-8/attachment updates we've made recently.

Wouter

Wouter

2009-07-21 07:27

reporter   ~0022541

I cant reproduce it with the latest 1.20 r1 dev version. I can't get to the login screen:
Fatal error: Call to undefined function user_pref_get_language() in ...\mantisbleedingedge\core\relationship_api.php on line 79

Apparently this is an UTF8 problem too (searched for relationship_api.php)

dhx

dhx

2009-10-26 08:22

reporter   ~0023338

What about 1.2.0RC2 (this contains a lot of bug fixes over RC1 related to attachments and filenames)?

dhx

dhx

2009-10-27 02:15

reporter   ~0023379

Aha, this was indeed a bug.

We were using urlencode() instead of rawurlencode() and thus spaces were being converted to + instead of %20

Browsers seem to expect %20 as a space in the Content-Disposition header.

Fixed in 1.2.x and 1.3.x for the next post 1.2.0RC2 release.

Thanks for reporting this bug and for helping debug the cause.

Related Changesets

MantisBT: master-1.2.x f2035d37

2009-10-27 02:02

dhx


Details Diff
Fix 0011075: Add Content-Disposition workaround for Internet Explorer/Chrome

Internet Explorer and Chrome don't support RFC2231 and also ignore the
fallback method currently implemented in MantisBT. See
http://greenbytes.de/tech/tc2231/#attfnboth2 for the current method.

We can however use another method to display UTF8 filenames to IE and
Chrome. This workaround is actually in breach in RFC2231. See
http://greenbytes.de/tech/tc2231/#attwithfnrawpctenclong for details. We
use this method when the user agent is determined to be IE or Chrome.
Otherwise we just keep using the original RFC2231 fallback technique
mentioned above.

It also appears that urlencode() is the wrong method to use for encoding
filenames. Browsers seem to expect %20 as a space instead of +. Thus we
should use rawurlencode() instead for the old method of encoding URLs.
RFC2231 actually contains examples with %20 being used.

Some minor cleanups were also performed in relation to sending the
Content-Disposition header and also performing browser checks.
Affected Issues
0009775, 0011075
mod - file_download.php Diff File
mod - core/http_api.php Diff File
mod - core/file_api.php Diff File
mod - print_all_bug_page_word.php Diff File

MantisBT: master 07c8da02

2009-10-27 02:02

dhx


Details Diff
Fix 0011075: Add Content-Disposition workaround for Internet Explorer/Chrome

Internet Explorer and Chrome don't support RFC2231 and also ignore the
fallback method currently implemented in MantisBT. See
http://greenbytes.de/tech/tc2231/#attfnboth2 for the current method.

We can however use another method to display UTF8 filenames to IE and
Chrome. This workaround is actually in breach in RFC2231. See
http://greenbytes.de/tech/tc2231/#attwithfnrawpctenclong for details. We
use this method when the user agent is determined to be IE or Chrome.
Otherwise we just keep using the original RFC2231 fallback technique
mentioned above.

It also appears that urlencode() is the wrong method to use for encoding
filenames. Browsers seem to expect %20 as a space instead of +. Thus we
should use rawurlencode() instead for the old method of encoding URLs.
RFC2231 actually contains examples with %20 being used.

Some minor cleanups were also performed in relation to sending the
Content-Disposition header and also performing browser checks.
Affected Issues
0009775, 0011075
mod - core/file_api.php Diff File
mod - core/http_api.php Diff File
mod - file_download.php Diff File
mod - print_all_bug_page_word.php Diff File