W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Content-Disposition filename encoding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 17 Mar 2008 10:49:35 +0100
Message-ID: <47DE3EAF.7070602@gmx.de>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
CC: ietf-http-wg@w3.org

Frank Ellermann wrote:
> Julian Reschke wrote:
>>> What is the idea of a Content-Disposition header field in HTTP/1.1 ?
>>> Why should a filename parameter make more sense than the relevant
>>> part of the URL, with its own security considerations in RFC 2616 ?
>> Some reasons I can think of right away...:
>> 1) Sometimes the last segment of the URL has no relationship with
>> what the filename should be.
> Hm...  I could also argue that wild and wonderful filename proposals
> might be irrelevant for the client depending on the file system.  If
> I store a file my browser lets me pick where, and under which name,
> and if I feel like it I put it on the 8+3 FAT partition (example).

Of course it's only a suggestion.

But tell an Asian customer that they have to retype the name whenever 
they do "Save As".

> I have no partition where case is significant (or maybe I do, but I
> have no driver to mount the Debian partition from W2K ;-)  For all
> folks laughing about NTFS and HPFS oddities I have one number:  *14*

NTFS in fact is case-sensitive, but most Windows APIs hide that. (In 
doubt, try Microsoft's Posix stuff).

>> 2) Even if it does, and that segment contains URI-escaped non-ASCII 
>> characters, there's no standard way to decode that into a character 
>> sequence (is it Latin-1? UTF-8? Something else?)
> Perecent-encoded URIs are always UTF-8, unless they can't be UTF-8,
> ignoring pure US-ASCII for the moment, US-ASCII is a proper subset.
> That's a consequence of RFC 3987, nothing else makes sense, but we
> are not supposed to talk about it:  RFC 3987 does NOT update 3986,
> except where it does in its own sneaky way (nothing wrong with it,
> but some really old ftp-URIs etc. might strongly disagree ;-) 

That's not relevant here.

Servers still encode non-ASCII characters using other character sets.

For instance (as far as I recall), for Apache on Unix it simply depends 
on what character set is used in the filesystem, which may depend on the 
  locale of the user who created that file (see, for instance, 

BR, Julian
Received on Monday, 17 March 2008 09:50:29 UTC

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