Re: Content-Disposition filename encoding

Julian Reschke wrote:

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

Don't know, I never try to impose a filename of my choice
on other folks in a MIME or HTTP Content-Disposition, I
would consider it on the border of net abuse to try this,
because I have no idea what their file system supports.

> RFC2231 (actually, a small profile of it) works just
> fine

Good, then let's say so.  In the USEFOR WG I tried about
a year to do anything, anything at all, to avoid RFC 2231,
but eventually I had to accept that all my proposals made
no sense for various reasons.

 [NTFS and case sensitive file names] 
> Yes, you can. You just need to use the proper API to
> access the file system.

I tested it now with pax.exe, you're right:

| D:\Programme\bin>pax -v -f test
| -rwx---r-x  0 Frank    Kein           30 Mar 24 16:26 AAbb
| -rwx---r-x  0 Frank    Kein           30 Mar 24 16:28 aaBB
| USTAR format archive
|
| D:\Programme\bin>pax -r -f test
|
| D:\Programme\bin>dir aa*
| Datenträger in Laufwerk D: hat keine Bezeichnung.
| Datenträgernummer: 1C81-013D
|
| Verzeichnis von D:\Programme\bin
|
| 2008-03-24  16:26                   30 AAbb
| 2008-03-24  16:28                   30 aaBB
|               2 Datei(en)             60 Bytes

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

Let's take 2231 "as is", implementations not supporting 
odd charsets can ignore the proposed file name, limiting
it to UTF-8 could be a bad idea if it's actually less
(us-ascii, latin-1, etc.) and the target platform can
only do less.  The strict length limits for RFC 2047 are
no issue for RFC 2231 parameters, or are they ?

 Frank

Received on Monday, 24 March 2008 15:51:25 UTC