View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011075 | mantisbt | attachments | public | 2009-10-24 09:06 | 2010-02-22 14:34 |
Reporter | watergad | Assigned To | dhx | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.0rc2 | ||||
Target Version | 1.2.0 | Fixed in Version | 1.2.0 | ||
Summary | 0011075: File downloading - IE vs non-IE filename bugs | ||||
Description | I cant find any recent file_download.php suitable for IE and Mozilla/Opera same time. file_download.php from rc1: file_download.php from rc2: file_download.php from 0011045 : | ||||
Additional Information | I've added silly tweak to the file_download.php from 0011045 file: // instead of This way both browsers work fine. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
duplicate of | 0010868 | closed | dhx | Problem with downloading of files those have cyrillic simbols in their names |
related to | 0006047 | confirmed | Mimetype of attached files. | |
has duplicate | 0011082 | closed | dhx | Unable to download attached file with Internet Explorer 7 & 8 |
has duplicate | 0011193 | closed | dhx | При скачивании приложенного файла не сохраняется первоначальное имя |
has duplicate | 0011202 | closed | dhx | attached images sent to browser without content type |
has duplicate | 0010402 | closed | dhx | Can't download attachments with IE |
Please see 0010868 and in particular the link I posted there... http://greenbytes.de/tech/tc2231/ These attachment download filename bugs are mostly a result of web browsers not supporting RFC2231. I tried to use a fallback technique that works for as many users as possible, with preference to ensuring that correctly implemented browsers work with UTF8 filenames (rather than being crippled because of competing browsers lagging behind). Also if you're seeing binary garbage on your screen when you expect to see a file download dialog, see bug 0006047 and the related/child bugs. This is a completely separate matter to the Content-Disposition header you refer to in this bug report. |
|
Strange thing, seems that I was wrong here about binary opening in RC2... As I have said here, it works if we use "filename="' ..." for IE8 (not filename*=UTF8...). I agree, maybe IE doesn't support RFC well, but what do customers understand about that? (: |
|
According to http://greenbytes.de/tech/tc2231/ IE8 ignores the Content-Disposition header MantisBT sends to it. That is the reason it is showing up as file_download.xxx in the file download dialog. We could add a browser hack for IE although your solution isn't quite right... we'd need to use an invalid approach (http://greenbytes.de/tech/tc2231/#attwithfnrawpctenclong) to get it working properly. In other words, urlencode() the filename in the Content-Disposition header. I usually hate hacky per-browser workarounds but in this case I can see why it's justified. I just want to make sure our browser detection method is precise enough to only target affected versions of IE (versions 0 to 8) and not other browsers or possible future versions of IE. |
|
OK it should be fixed now. Can you please test and confirm? Thanks |
|
Sure, I completely agree that per-browser workarounds must die. |
|
Yes, works great (as for the wrong IE8 as for the Seamonkey) Thank you very much! |
|
Yeah I decided to just assume that IE9 won't include RFC2231 support either :p I don't understand your comment about IE8/Seamonkey. Are you saying that everything works well with those browsers now... or are they broken? Can you please also try downloading the empty text file I'm about to attach to this bug. I'll use Chinese characters in the filename... hopefully with Internet Explorer you'll see Chinese characters in the file download dialog window. |
|
I've patched our Mantis and tried to download cyrillic-named files. Chinese characters here:
|
|
Thanks watergad... squares are good! It's an indication that IE tried to render the Unicode Chinese characters, but couldn't because you don't have the correct Chinese font installed. This issue sounds like it's solved now. Thanks for your help! |
|
This patch fixes 1.2.0rc2 for me |
|
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 | ||
MantisBT: master-1.2.x faa14562 2009-10-27 04:29 Details Diff |
Issue 0011075: Fix copy/paste error in file_get_extension Commit 07c8da02a96216b87842190cca2777e82a668d1f introduced a copy/paste error within the file_get_extension function that prevented it from splitting the extension off a filename. |
Affected Issues 0011075 |
|
mod - core/file_api.php | Diff File | ||
MantisBT: master 13403565 2009-10-27 04:29 Details Diff |
Issue 0011075: Fix copy/paste error in file_get_extension Commit 07c8da02a96216b87842190cca2777e82a668d1f introduced a copy/paste error within the file_get_extension function that prevented it from splitting the extension off a filename. |
Affected Issues 0011075 |
|
mod - core/file_api.php | Diff File |