- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 26 Feb 2011 12:12:23 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
On 25.02.2011 11:11, Julian Reschke wrote:
> On 24.02.2011 08:54, Julian Reschke wrote:
>> On 24.02.2011 06:39, Mark Nottingham wrote:
>>> I wouldn't say we break FireFox by recommending this ("breaking" means
>>> that C-D doesn't work at all, or produces garbage), and I wouldn't say
>>> they've been doing the right thing (because they implemented to prefer
>>> the non-internationalised filename).
>>
>> When I said "break" I mean that sending a I18Nized filename will not
>> have the desired effect.
>> ...
>
> Looking at <https://bugzilla.mozilla.org/show_bug.cgi?id=588781#c21>,
> the fix will go into Firefox 5, which is planned to be 3 months behind
> Firefox 4.
>
> Optimally, this would be ~July 2011.
>
> On the other hand, to get to RFC we need
>
> - to do the IETF LC -> two weeks
> - get it through the IESG (I expect at least minimally one revision to
> be requested) -> ~ two months
>
> Once it's in the RFC publication queue, it'll take at least another six
> weeks... Which would be around the same time.
>
> Still, I'm very uncomfortable recommending something we're not sure will
> work when the RFC is published.
> ...
Ok, after lots of wordsmithing by Mark and myself we now have this:
-- snip --
Appendix D. Advice on Generating Content-Disposition Header Fields
To successfully interoperate with existing and future user agents,
senders of the Content-Disposition header field are advised to:
o Include a 'filename' parameter when US-ASCII is sufficiently
expressive.
o Use the 'token' form of the filename parameter only when it does
not contain disallowed characters (e.g., spaces); in such cases,
the quoted-string form should be used.
o Avoid including the percent character followed by two hexadecimal
characters (e.g., %A9) in the filename parameter, since some
existing implementations consider it to be an escape character,
while others will pass it through unchanged.
o Avoid including the "\" character in the quoted-string form of the
filename parameter, as escaping is not implemented by some user
agents, and can be considered as an illegal path character.
o Avoid using non-ASCII characters in the filename parameter.
Although most existing implementations will decode them as ISO-
8859-1, some will apply heuristics to detect UTF-8, and thus might
fail on certain names.
o Include a 'filename*' parameter where the desired filename cannot
be expressed faithfully using the 'filename' form. Note that
legacy user agents will not process this, and will fall back to
using the 'filename' parameter's content.
o When a 'filename*' parameter is sent, to also generate a
'filename' parameter as a fallback for user agents that do not
support the 'filename*' form, if possible. This can be done by
substituting characters with US-ASCII sequences (e.g., Unicode
character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by
"ae"). Note that this may not be possible in some locales.
o When a 'filename' parameter is included as a fallback (as per
above), 'filename' should occur first, due to parsing problems in
some existing implementations. [[fallbackbug: Firefox is known to
pick the wrong parameter; a bug fix is scheduled for Firefox 5.
--jre]]
o Use UTF-8 as the encoding of the 'filename*' parameter, when
present, because at least one existing implementation only
implements that encoding.
Note that this advice is based upon UA behaviour at the time of
writing, and might be superseded.
<http://purl.org/NET/http/content-disposition-tests> provides an
overview of current levels of support in various implementations.
-- snip --
Where <http://purl.org/NET/http/content-disposition-tests> currently
redirects to <http://greenbytes.de/tech/tc2231/>.
See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1142>.
Best regards, Julian
Received on Saturday, 26 February 2011 11:13:11 UTC