Re: Content-Disposition filename encoding

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).

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*

> 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 ;-) 

 Frank

Received on Monday, 17 March 2008 09:22:00 UTC