Re: Fwd: Content-Disposition and IE

On 13.12.2010 22:03, Mark Nottingham wrote:
> Eric Lawrence asked me to forward this to the list:
>
>> Adding new features to support Download Filenames isn't the sort of thing IE tends to do servicing for, so our IE8 and below behavior likely will never change (e.g. no support for backslash encoding, we always attempt to decode %-encoding as UTF-8; more details here: http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx. The most I can imagine that we would do for downlevel IE versions is fix the bug whereby encountering a filename* token in the C-D header aborts our search for a legacy ("non-RFC2231") filename token.
>>
>> Moving forward, it should be straightforward to add limited support for RFC2231/5987-style UTF-8 encoding in for IE9. This would consist of finding the filename* token, eating the =UTF-8'.*' that follows it, and passing the %-encoded filename to our legacy routines. We'd use the filename* token in preference to the legacy filename token, regardless of ordering. We still wouldn't support backslash encoding, and we wouldn't support codepages other than UTF-8.  While limited, these small tweaks should improve our interop story moving forward. Generally speaking, well-formed RFC5987-style C-D headers using UTF-8 would work interoperably across browsers.
>>
>> Thanks,
>> -Eric Lawrence

Hi Eric,

thanks for the feedback.

Two comments:

1) When you say "...and passing the %-encoded filename to our legacy 
routines..." -- please make sure that the legacy routines really don't 
do anything except percent-unescaping, then UTF-8 decoding. Any kind of 
sniffing, or guessing of charsets in this context would damage the 
usability of the encoding -- so I'm nervous when you say that you want 
to pass things to legacy code, in particular when it's for something as 
trivial as the decoding mentioned above.

2) It's a bit unfortunate that we had an open question about whether we 
should throw out ISO-8859-1 as REQUIRED encoding in RFC 5987; we asked 
around multiple times, and as we didn't get any clear feedback we 
didn't. So, if you're going to make changes to IE anyway, I'd like to 
encourage you to also implement ISO-8859-1 (it could be done by an 
additional preprocessing step if keeping the legacy code in use is 
really important to you).

Best regards, Julian

Received on Monday, 13 December 2010 21:18:55 UTC