View Issue Details

IDProjectCategoryView StatusLast Update
0011075mantisbtattachmentspublic2010-02-22 14:34
Reporterwatergad Assigned Todhx  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.2.0rc2 
Target Version1.2.0Fixed in Version1.2.0 
Summary0011075: 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:
IE - ok, non-IE - %%-like filenames

file_download.php from rc2:
IE - opens binary without file dialog, non-IE - ok

file_download.php from 0011045 :
IE - file_download.xls-like filenames, non-IE - ok

Additional Information

I've added silly tweak to the file_download.php from 0011045 file:

// instead of
// header( 'Content-Disposition:' . $t_disposition . ' filename=UTF-8\'\'' . urlencode( $t_filename ) . '; filename="' . urlencode( $t_filename ) . '"' );
// adding:
if ( preg_match( "/MSIE/", $_SERVER["HTTP_USER_AGENT"] ) ) {
// that's how it was in RC1
header( 'Content-Disposition:' . $t_disposition . ' filename="' . urlencode( $t_filename ) . '"' );
} else {
// that's how it's in RC2
header( 'Content-Disposition:' . $t_disposition . ' filename
=UTF-8\'\'' . urlencode( $t_filename ) . '; filename="' . urlencode( $t_filename ) . '"' );
}

This way both browsers work fine.

TagsNo tags attached.
Attached Files
海納百川.txt (7 bytes)   
abc123
海納百川.txt (7 bytes)   

Relationships

duplicate of 0010868 closeddhx Problem with downloading of files those have cyrillic simbols in their names 
related to 0006047 confirmed Mimetype of attached files. 
has duplicate 0011082 closeddhx Unable to download attached file with Internet Explorer 7 & 8 
has duplicate 0011193 closeddhx При скачивании приложенного файла не сохраняется первоначальное имя 
has duplicate 0011202 closeddhx attached images sent to browser without content type 
has duplicate 0010402 closeddhx Can't download attachments with IE 

Activities

dhx

dhx

2009-10-26 07:39

reporter   ~0023330

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.

watergad

watergad

2009-10-26 14:11

reporter   ~0023356

Strange thing, seems that I was wrong here about binary opening in RC2...
Sorry, you're right, duplicate of 0010868
But there's still one problem: if I open file (e.g. from 0010868 ) with IE8 I have a file dialog with a "file_download.pdf" instead of the desired filename.

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? (:
I've solved this problem for me as described above so you can close issue if nobody cares about IE

dhx

dhx

2009-10-27 00:49

reporter   ~0023376

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.

dhx

dhx

2009-10-27 02:10

reporter   ~0023377

OK it should be fixed now. Can you please test and confirm?

Thanks

watergad

watergad

2009-10-27 02:11

reporter   ~0023378

Sure, I completely agree that per-browser workarounds must die.
The "solution" I use here is nothing but a temporarily lame tweak by me (do note everyone who doesn't understand how it works).
And you're right about preventing "patching" later IE versions, I didn't think about it.
Thanks.

watergad

watergad

2009-10-27 02:19

reporter   ~0023381

Yes, works great (as for the wrong IE8 as for the Seamonkey)

Thank you very much!

dhx

dhx

2009-10-27 02:23

reporter   ~0023382

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.

watergad

watergad

2009-10-27 03:07

reporter   ~0023383

I've patched our Mantis and tried to download cyrillic-named files.
Both Seamonkey and IE works fine.

Chinese characters here:

  • works fine in Seamonkey (ok displaying on the page, ok displaying in the file dialog, fail on the file naming step, fail saving to the disk - fails of the OS, chinese charsets are not installed)
  • and fails in IE (displaying "squares" on the page, "file_download.php" in the file dialog).
dhx

dhx

2009-10-27 03:16

reporter   ~0023384

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!

rledford

rledford

2009-12-29 12:21

reporter   ~0024009

This patch fixes 1.2.0rc2 for me

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

MantisBT: master-1.2.x faa14562

2009-10-27 04:29

dhx


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

dhx


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