A recent support call that came in discussed a problem concerning downloading files from an ADAM system with the Internet Explorer family of browsers. The problem occured when downloading files with non-ASCII characters in the filename, using the following code:

1

    AdamDownloader.DownloadFile(this, path, true);

On the client side, this results in the following dialog shown to the user:

This is a particular hard problem to solve, as there is no single solution that will work for all browsers. Let me explain...

First, I need to explain that this is not a problem with ADAM itself. The same problem can be reproduced in a simple Web Application project. You use the following code to specify the filename in ASP.NET:

1
2
3

    string filename = "test.jpg";
    Response.AppendHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
    Response.TransmitFile(MapPath("~/Content/file.jpg"));

This particularly small snippet of code works fine, as long as your filenames do not contain any non-ASCII characters.

By default, all headers are encoded in UTF-8 by the webserver. This is not standard behaviour, as RFC 2047 recommends that headers are encoded in ISO 8859-1. However, it seems that allmost all browsers are broken when it comes to supporting this encoding.

Here you can find a detailed test for various methods to specifying filenames in response headers, and how different browsers respond to it. It seems that Internet Explorer is the more strict, in treating all headers as ISO 8859-1 as per standard, while FireFox 3 is more relaxed in allowing this header to be encoded in UTF-8. That also means that an ISO 8859-1 string that resembles an UTF-8 string is misunderstood by FireFox as being UTF-8. This can lead to interesting effects.

At first one would think changing the default encoding in IIS 7 from UTF-8 to ISO 8859-1. Alas, this doesn't work. I've tried it and the fairly common é is returned as byte sequence 0xBF, 0xEF, 0xBD, which is a disaster to all browsers. Why this happens I haven't found out yet.

Changing the header encoding in code, did work for me, however:

1
2
3
4

    string filename = "tést.jpg";
    Response.HeaderEncoding = System.Text.Encoding.GetEncoding("iso-8859-1");
    Response.AppendHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
    Response.TransmitFile(MapPath("~/Content/file.jpg"));

This worked in IE8, FF3, Chrome and Safari, but not Opera. It will also not work with filenames that contain characters outside of ISO 8859-1, as those characters cannot be represented in any way in this encoding, unlike UTF-8.

Another candidate solution is to use RFC 2231 compliant encoding of URLs in this header. This is easily accomplished:

1
2
3

    string filename = HttpUtility.UrlPathEncode("tést.jpg");
    Response.AppendHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
    Response.TransmitFile(MapPath("~/Content/file.jpg"));

And this will work in IE8 and Chrome, but not in FF3, Safari or Opera which will show garbled filenames. These browsers only support the following way:

1
2
3

    string filename = HttpUtility.UrlPathEncode("tést.jpg");
    Response.AppendHeader("Content-Disposition", "attachment; filename*=utf-8''\"" + filename + "\"");
    Response.TransmitFile(MapPath("~/Content/file.jpg"));

This forum post also discusses a third method using path info, but that is also not a general solution as it can only be used in IIS, not the Development Server, and only if you can somehow treat your downloads as a file from a certain server path.