Subject: Fwd: Content-Disposition and IE

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Dec 2010 08:03:40 +1100

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

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 22:18:18 +0100

>> 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…

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 14 Dec 2010 15:52:14 +0900

> really important to you).

What about letting IE do things without ISO-8859-1, and in due time 
removing that from (a succesor of) RFC 5987? ISO-8859-1 for HTTP may 
have been a good idea in 1990, but it has long ago ceased to be anything 
else than a heavy burden.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Dec 2010 08:07:53 +0100

On 14.12.2010 07:52, "Martin J. Dürst" wrote:
> ...
> ...

That's a possibility. If we can get IE and Safari to support RFC 5987, 
the problem that I wanted to solve in the first place  (missing interop 
for I18N) will be gone.

When we revise RFC 5987 for Draft Standard -- and I plan to do this as 
soon as possible -- when could then remove the requirement to support 
ISO-8859-1 as well.

Best regards, Julian