W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Aug 2008 19:00:08 +0200
Message-ID: <48A85918.70409@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: "'William A. Rowe, Jr.'" <wrowe@rowe-clan.net>, ietf-http-wg@w3.org

Brian Smith wrote:
> 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

I disagree. It's totally useful, and it seems lots of people agree with 
  Mark's current draft.

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

I don't see how that helps for the cases the Link header tries to 
handle. Unless you want to mandate PROPFIND or a similar metadata 
discovery 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).

OK, two out of the four most widely used desktop browsers.

> 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

Well, that would make the parsing non-compliant with the specs. Are you 
aware of any pages that actually use that format?

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

I've never been able to reproduce this on my own systems, but I did have 
Korean customers complaining *and* Microsoft admitting there's no 
reliable way to do it in IE (because the behavior relies on local 
settings the server can't see).

WRT IE8beta1: I checked some time ago, and the behavior seemed to be the 
same as in previous releases.

BR, Julian
Received on Sunday, 17 August 2008 17:00:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC