Re: Content-Disposition filename encoding

Frank Ellermann wrote:
> Julian Reschke wrote:
>  
>> As RFC2616 doesn't really include Content-Disposition, nor requires 
>> RFC2231, it doesn't seem to be in our charter to do something.
> 
> The MIME registry points to RFC 4229, which points to RFC 2616, and
> from RFC 2616 I find RFC 1806 as amended by RFC 2183.  For obscure
> reasons RFC 2183 was updated by RFC 2184, and later by RFC 2231.  
> RFC 2184 was later obsoleted by RFC 2231.

Oh, I missed the 2184 step :-)

Does anybody know why RFC2183 does not obsolete RFC1806?

> That's rather confusing, but with 1806 < 2183 < 2184 < 2231 < 2616
> I'd say it's a bug in RFC 2616.  FWIW, RFC 2183 and RFC 2231 are PS,
> RFC 1806 is or was an experiment.

Let's summarize:

- RFC2616 should stop talking about RFC1806, this is just historic 
information
- RFC2616 will have to continue to document Content-Disposition as 
"additional feature"
- RFC2616 includes some vague statements about security risks, but 
doesn't say what they are; should it do so, or are they adequately 
documented in RFC2183? (in which case we it could just point to them)
- RFC2183 already requires support for RFC2184, later obsoleted by 
RFC2231; so recipients implementing Content-Disposition as per RFC2183 
will need to implement RFC2231 as well.

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

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

BR, Julian

Received on Monday, 17 March 2008 08:48:40 UTC