View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009775 | mantisbt | upgrade | public | 2008-11-04 19:12 | 2010-02-22 14:35 |
Reporter | llattan | Assigned To | dhx | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | x86_64 | OS | RedHat Enterprise Linux | OS Version | 5.2 |
Product Version | 1.1.4 | ||||
Fixed in Version | 1.2.0 | ||||
Summary | 0009775: Unable to download attachments with spaces in the filename | ||||
Description | I have mantis 1.0.7 on RHEL 5.2 x86_64. For example: Mantis 1.0.7 on RHEL 5.2 x86_64 Same machine, after upgrade: Mantis 1.1.4 on RHEL 5.2 x86_64 The filename in issue appears right. Is this a bug ? Thanks in advance. | ||||
Steps To Reproduce | I did the upgrade procedure. | ||||
Tags | No tags attached. | ||||
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. |
|
No longer targetting 1.1.5. |
|
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. |
|
When the solution will be targetted ? In which version ? Regards. |
|
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. |
|
This is one of serious issue because I'm still using the 1.1.0 version. |
|
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. |
|
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. |
|
Could anybody help me ? |
|
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. |
|
I know that Mantis is a open source project. 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. |
|
I wonder if I upgrade my system from version 1.0.7 to version 1.2.0 the problem will be fixed. |
|
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). |
|
Hi, Config: PHP 5.2.9-pl2-gentoo with Suhosin-Patch 0.9.7 (Gentoo), apache 2.2.1 (running on PPC32 Gentoo). |
|
I'm storing files on DB (Mantis 1.0.7 on RHEL 5.2 x86_64) and the problem is the same. |
|
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. |
|
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. |
|
I cant reproduce it with the latest 1.20 r1 dev version. I can't get to the login screen: Apparently this is an UTF8 problem too (searched for relationship_api.php) |
|
What about 1.2.0RC2 (this contains a lot of bug fixes over RC1 related to attachments and filenames)? |
|
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. |
|
MantisBT: master-1.2.x f2035d37 2009-10-27 02:02 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 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 |