Re: Content-Disposition filename encoding

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> tell an Asian customer that they have to retype the name whenever 
>> they do "Save As".
> 
> Beats me, I guess that these platforms allow ASCII file names among

And do you really believe that this is acceptable for the average customer?

> others.  I18N of file systems is an interesting topic, but for HTTP
> I think we can simply say that RFC 2231 is a possible solution, and
> finding something better is no job for a HTTP/1.1 2616bis.  

I didn't propose to find something better.

RFC2231 (actually, a small profile of it) works just fine; it just seems 
that some UA vendors (MS, Apple) believe they don't need to implement it.

> ...
>> NTFS in fact is case-sensitive, but most Windows APIs hide that.
>> (In doubt, try Microsoft's Posix stuff).
> 
> Of course I can have a file AAbb, but I can't have aaBB in the same

Yes, you can. You just need to use the proper API to access the file system.

> ...
> Whenever we get down to individual servers like apache, individual
> browsers like IE, or here individual file systems, I think we miss
> the point:  2616bis has to specify something working for everybody
> based on 2616.  And where apache, IE, HTML5, IIS, atom, etc. do
> something else it's their problem.  If they all happen to agree on
> what they do, we are free to align the theory with common practice.
> And I'll scream if it breaks the oldest curl or wget I can find :-)

Well, we have an I18N problem, and a solution for it (RFC2231). Some 
vendors implement it (FF, Opera), others don't. The question is: can we 
improve the documentation of Content-Disposition so that it becomes 
clear that RFC2231 support is required? Furthermore, should we simplify 
things by stating precisely what parts of RFC2231 are really needed (the 
line folding is not needed, and support for a single charset (UTF-8) 
would be sufficient)?

BR, Julian

Received on Monday, 24 March 2008 10:52:37 UTC