W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Fwd: Content-Disposition and IE

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 14 Dec 2010 08:03:40 +1100
To: httpbis Group <ietf-http-wg@w3.org>
Message-Id: <62F48897-6BD4-427A-96AC-59E2F2C6C66B@mnot.net>
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/
Received on Monday, 13 December 2010 21:04:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC