RE: Factoring out Content-Disposition (i123), was: Content-Disposition (new issue?)

Julian Reschke wrote:
> William A. Rowe, Jr. wrote:
> > Brian Smith wrote:
> >> Since the primary (only?) use case for RFC2231 in HTTP is the 
> >> Content-Disposition header, why not just fold this into the spec. 
> >> that you are writing for Content-Disposition? URI references are 
> >> already ASCII-encoded IRIs, and Atom's Slug header field 
> already has 
> >> its own mechanism for handling non-ASCII text.
> 
> (to Brian) The interoperability problems with 
> Content-Disposition motivated me to work on this, right. But 
> putting the RFC2231 profile for HTTP into the same spec as a 
> discussion of Content-Disposition would mean conflating 
> separate issues. Furthermore, RFC2231-style encoding could be 
> used in other headers as well, such as in the title parameter 
> for the Link header (which clearly should support I18N, but 
> can't be sent in the entity body).

Like I've said before, the Link header field is more trouble than it is
worth. The i18n problems with the title attribute are not even the biggest
problem with it. Links can be sent in entity bodies, even for media types
like image/png that do not have their own linking mechanism; see AtomPub's
media link entries and WebDAV's analogous property mechanism.

> Doesn't work for me. We *know* that RFC2231-encoding already 
> is in use, and that 2 out of 4 UAs have been supporting it 
> for a long time.

I know you are not trying to be misleading, but "2 out of 4" is definitely
an exaggeration. There are way more than four different web browsers in
common use and I'm not sure that Opera is even in the top four when you
count mobile browsers (especially Docomo's browser, Nokia's browser, and
NetFront).

I'm thinking of writing a submitting for Firefox that decodes the
Content-Disposition filename parameter as escaped UTF-8 if it is not
RFC2231-encoded. I am interested in your test cases that demonstrate IE's
behavior for escaped UTF-8 filenames. I am especially interested in the East
Asian test cases where IE decoded the filename incorrectly; I have not been
able to duplicate that problem in IE6 or IE7. I am also curious if you have
found any changes to IE8 beta 1's behavior.

Thanks,
Brian

Received on Sunday, 17 August 2008 16:46:58 UTC