Downloads and International Filenames

re: Downloads and International Filenames

Sandip — Tue, 23 Oct 2012 06:32:25 GMT

Update u are talking about IE9

Update: IE9 now supports RFC5987/RFC2231 formatted tokens using the UTF-8 character encoding. IE9 prefers the filename* token over the filename token, although, for legacy compatibility, you should send the filename token before the filename* token.

Still issue persist with IE9.

Is it fixed with IE9 or next version u talk about?

re: Downloads and International Filenames

Julian Reschke — Mon, 12 Sep 2011 16:54:08 GMT

In the meantime, the IETF has published RFC 5987 (for encoding parameters in HTTP header fields) and RFC 6266 (about Content-Disposition in HTTP).

Also, Chrome (with version 9) and Internet Explorer (also with version 9, for UTF-8 only) support the encoding, and Firefox 5 fixed the problem of defaulting to the wrong variant when both are present.

Opera and Konqueror have been supporting the notation for long.

Thus, "filename*" (with UTF-8 encoding) can be used interoperably for all current browsers (except the one I didn't mention above).

A revision to RFC 5987 is likely to remove the requirement to support ISO-8859-1, in which case IE9 will be "fully" compliant.

Best regards, Julian

re: Downloads and International Filenames

EricLaw [MSFT] — Wed, 22 Dec 2010 20:51:42 GMT

Recently, we found a system where download of files with non-ASCII characters in the filename consistently failed. It turns out that the system in question had "short filename generation" disabled on the volume where Temporary Internet Files are stored. This causes an internal failure of the long-filename handling code, and IE will not be able to download files with non-ASCII characters in the name.

The quick way (on Win7) to see if this is the problem is to run the following command from a command prompt:

fsutil 8dot3name query C:

(Where C: is the drive containing your TIF). If the result is "Based on the above two settings, 8dot3 name creation is enabled on C:" then you should not encounter this problem.

re: Downloads and International Filenames

Matt — Thu, 23 Sep 2010 22:57:18 GMT

"largish" is somewhere between 4 and 8%? Hrm...

en.wikipedia.org/.../Usage_share_of_web_browsers

re: Downloads and International Filenames

Julian Reschke — Thu, 23 Sep 2010 22:52:22 GMT

Eric.

peace :-).

In 2004, FF already had a largish market share, and back then was the only serious contender to IE. This is not "spotty".

And no, I don't want to impose ordering requirements. There are none of these in the proposed spec. What it *does* say is that if you choose a particular ordering, your chances of UAs doing the right thing are better. This is simply a fact, and only relevant until UAs have their parsing related bugs fixed.

Best regards, Julian

re: Downloads and International Filenames

EricLaw [MSFT] — Thu, 23 Sep 2010 13:29:52 GMT

I'm not really interested in debating whether or not a browser with tiny (in 2004, at least) marketshare that partially supports a feature if-and-only-if you use it in a particular way (which AFAIK was never documented) constitutes "spotty" support. We can simply agree to disagree.

As to the latter point, I've stated my opinion that imposing arbitrary ordering requirements on HTTP value parameters seems like a sub-optimal design. You've suggested that you disagree, and since you're writing the RFC, not me, I suspect I know how that's going to turn out.

re: Downloads and International Filenames

Julian Reschke — Thu, 23 Sep 2010 06:04:06 GMT

Eric,

Firefox has been supporting "filename*" for over 6 years. Back then, it was the one usable alternative to IE, so I wouldn't call that "spotty" :-)

With respect to calling "filename*" problematic: my test cases show that it can be sent to IE today, as long as it's preceded by "filename". You know, "same markup" (even though in headers, not HTML).

Best regards, Julian

re: Downloads and International Filenames

EricLaw [MSFT] — Wed, 22 Sep 2010 22:04:29 GMT

While the IETF spec may be 13 years old, support for "filename*" has been extremely sparse, at best. My suggestion is merely that using a different token (e.g. "name*") is more likely to spur adoption than sticking with a known-problematic token.

If by "temporary" you mean "however many years it takes for users to upgrade to newer browsers" then yes, I think we're agreed.

re: Downloads and International Filenames

Julian Reschke — Wed, 22 Sep 2010 21:54:19 GMT

Eric,

with "duplicating the functionality" I was referring to the fact that the IETF has recommended a way to do this for many years (to be precise, since August 1997), and three browser implementations implement that.

Adding a new parameter "name*" that works exactly as "filename*" would duplicate functionality that's already implemented and deployed. It would be an alias (with the usual impact that we would need to think about what happens when both "filename*" and "name*" are present).

It would certainly be *easier* to simply have a single approach.

That ordering would become significant certainly is a drawback, but it would be only a temporary workaround. From that point of view, I don't think it's something to be concerned about.

Best regards, Julian

re: Downloads and International Filenames

EricLaw [MSFT] — Wed, 22 Sep 2010 21:35:09 GMT

I'm not aware of other features that impose ordering requirements on HTTP header tokens. The problem goes away if the "new" token does not contain a string match for the "old" token. I have no idea what "duplicating the functionality" means.