Subject: Content-Disposition (new issue?)

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 11:58:29 +0200

Hi,

looking at 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-03.html#content-disposition>:

----
B.1 Content-Disposition

The Content-Disposition response-header field has been proposed as a 
means for the origin server to suggest a default filename if the user 
requests that the content is saved to a file. This usage is derived from 
the definition of Content-Disposition in [RFC1806].

   content-disposition = "Content-Disposition" ":"
                         disposition-type *( ";" disposition-parm )
   disposition-type = "attachment" | disp-extension-token
   disposition-parm = filename-parm | disp-extension-parm
   filename-parm = "filename" "=" quoted-string
   disp-extension-token = token
   disp-extension-parm = token "=" ( token | quoted-string )

An example is

      Content-Disposition: attachment; filename="fname.ext"

The receiving user agent SHOULD NOT respect any directory path 
information present in the filename-parm parameter, which is the only 
parameter believed to apply to HTTP implementations at this time. The 
filename SHOULD be treated as a terminal component only.

If this header is used in a response with the application/octet-stream 
content-type, the implied suggestion is that the user agent should not 
display the response, but directly enter a `save response as...' dialog.

See Section 8.2 for Content-Disposition security issues.
----

It seems that certain vendors do not "get" that RFC1806 was updated by 
RFC2183, which in turn was updated by RFC2231 (defining I18N).

So I think we need to

1) s/1806/2183/g (this is editorial, methinks)

2) Clarify that I18N is defined in by RFC2231

3) Specify a profile of RFC2231 that makes sense for Content-Disposition 
as used over HTTP (as opposed to mail), such as:

3a) No Continuations 
(<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>)

3b) Support 
<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>, but only 
use UTF-8 encoding in producers.

Feedback appreciated,

Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 20 Jun 2008 13:32:39 +0200

Julian Reschke wrote:

> It seems that certain vendors do not "get" that RFC1806 was updated
> by RFC2183, which in turn was updated by RFC2231 (defining I18N).

> 1) s/1806/2183/g (this is editorial, methinks)

+1

> 2) Clarify that I18N is defined in by RFC2231

+2

> 3) Specify a profile of RFC2231 that makes sense for 
>    Content-Disposition as used over HTTP (as opposed to
>    mail), such as:

Generally, not only for Content-Disposition "experiments",
right ?

> (<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>)

+1  Wow, I only saw "greenbytes" and thought that you are talking
    about an editor's copy of one of the 2616bis parts.  And was
    completely confused why you apparently specify the same idea
    as RFC 2231 announced as *no* continuations.  Finally I saw
    that this just your HTMLified copy of RFC 2231. 

> 3b) Support 
* <http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.4>,
> but only use UTF-8 encoding in producers.

-1  Tiny mazes, all different... :-(  The us-ascii example is
    perfect, and if 2616bis sticks to its iso-8859-1 "default"
    this relic and its more popular windows-1252 incarnation are
    also plausible.  I can see a "strongly RECOMMENDED", but no
    MUST utf-8 here, and "default" iso-8859-1 there, and a big
    mess everywhere.   

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 13:42:19 +0200

Frank Ellermann wrote:
> ...
> ...

Well, we need one encoding that can represent all Unicode code points, 
and UTF-8 comes to mind for that. Support for RFC2231 in UAs would be 
totally pointless if we couldn't require recipients to understand it. So 
why produce anything else?

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 20 Jun 2008 14:15:02 +0200

>> -1  Tiny mazes, all different... :-(
[...]
>> no MUST utf-8 here, and "default" iso-8859-1 there, and a big
>> mess everywhere.   
 
> Well, we need one encoding that can represent all Unicode code
> points, and UTF-8 comes to mind for that.

Sure, maybe I don't understand what you are proposing.  The 2231
example is:

| Content-Type: application/x-stuff;
|  title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

This would also work for utf-8, iso-8859-1, and windows-1252 --
these charsets use the same encoding for u+0020, u+002A, "This",
and "fun".

I thought that you want to limit the choice to utf-8, which is
kind of odd in an environment with "default" iso-8859-1.  Maybe
somebody has implemented RFC 2231 in the last decade for HTTP.
(without those odd continuations relevant for mail, hopefully)

> Support for RFC2231 in UAs would be totally pointless if we
> couldn't require recipients to understand it. So why produce
> anything else?

How can an UA not understand iso-8859-1 if it is the "default",
or not support us-ascii as proper subset of utf-8, or not grok
windows-1252, which is what folks anyway do when they allegedly
use iso-8859-1 ?  You could say "MUST at least support us-ascii
and utf-8, and using one of these charsets is RECOMMENDED", or 
similar.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 14:38:36 +0200

> these charsets use the same encoding for u+0020, u+002A, "This",

That's true. But what we need is something that also works for "äöüß€" & 
friends *reliably*.

> (without those odd continuations relevant for mail, hopefully)

FF and Opera support RFC2231, and they do support UTF-8.

Reminding UAs to implement RFC2231 without stating that they really need 
also support the UTF-8 encoding seems like a bad idea.

And as there's no way for feature discovery/negotiation, sites really 
need a universal encoding they can count on.

> and utf-8, and using one of these charsets is RECOMMENDED", or 

Not sure what mentioning "us-ascii" buys as here, as the UTF-8 encoding 
is the same anyway. So requiring *both* doesn't give us any additional 
functionality whatsoever.

The second part of the sentence sounds ok, but seems to be really 
useless. If senders can rely on recipients understanding UTF-8, there is 
zero reason to ever try something else.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 15:00:26 +0200

>> 1) s/1806/2183/g (this is editorial, methinks)

I just noticed that in a different place, the spec cites RFC 1806 and 
then goes on saying it was updated by RFC 2183. Citing RFC 1806 seems to 
be only useful in order to tell the history of the header, which I think 
isn't what the HTTP spec is for.

Thus I'd propose to get rid of the RFC 1806 reference, and streamline 
the prose accordingly.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 18:50:50 +0200

> Thus I'd propose to get rid of the RFC 1806 reference, and streamline 

Issue: <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/121>

Fixed with: <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/269>

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 14:07:49 +0000

Brian Smith wrote:
> ... Documenting the *real* current situation would be much more useful, even though the current situation sucks; at least if people know the problem they can try to work around it. Especially, it would be great if there were some public test cases that describe the problem.
> ...

The problem is that there simply is no workaround for IE that works 
independently of the locale IE is running in. (Yes, we did report the 
issue to Microsoft back in 2004, and they were unable to provide a 
solution that would work the same way with IE across all locales)

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 20 Jun 2008 14:54:48 +0000

Julian Reschke wrote:
> Brian Smith wrote:
> > ... Documenting the *real* current situation would be much 
> more useful, even though the current situation sucks; at 
> least if people know the problem they can try to work around 
> it. Especially, it would be great if there were some public 
> test cases that describe the problem.
> > ...
> 
> The problem is that there simply is no workaround for IE that 
> works independently of the locale IE is running in. (Yes, we 
> did report the issue to Microsoft back in 2004, and they were 
> unable to provide a solution that would work the same way 
> with IE across all locales)

Could you please share a test case? Every time I tried to reproduce the
problem I could not.

Regards,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 15:06:30 +0000

> Could you please share a test case? Every time I tried to reproduce the

For IE, the only way (I'm aware of) to provide non-ASCII characters in 
the Content-Disposition filename parameter is to use percent encoding, 
such as

   Content-Disposition: attachment;
     filename=%c3%a4%c3%b6%c3%bc%c3%9f%e2%82%ac.txt

for a filename of "äöüß€".

The issue with that is that what character encoding IE chooses to 
*decode* the byte sequence depends on locale and IE configuration. For 
instance, in western countries it uses UTF-8, while in Asian locales, it 
uses something else, *except* when the config option "send URLs in 
UTF-8" is selected (which IMHO is *not* the default over there).

And even *if* this would work across all IE installations, it would 
break all the other UAs, which take the parameter value verbatim.

Adding support for RFC2231 (or a profile of it) should be trivial for 
Microsoft, as currently, a parameter such as

   Content-Disposition: attachment; *filename=charset'lang'value

is simply ignored.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 20 Jun 2008 13:53:18 +0000

Julian Reschke wrote:
> That's true. But what we need is something that also works 
> for "äöüß€" & friends *reliably*.
> 
> Reminding UAs to implement RFC2231 without stating that they 
> really need also support the UTF-8 encoding seems like a bad idea.

I don't see how Microsoft can change IE's parsing of Content-Disposition to match RFC2231 without breaking backward compatibility with itself. If they refuse to change then this change to the spec would be actively harmful as it would mislead readers into doing the wrong thing >80% of the time. Documenting the *real* current situation would be much more useful, even though the current situation sucks; at least if people know the problem they can try to work around it. Especially, it would be great if there were some public test cases that describe the problem.

Personally, I think the most realistic solution to the problem is a new Content-Filename header field that uses whatever encoding of UTF-8 is standardized in HTTPbis. If Content-Filename isn't provided then fall back to  Content-Disposition. *Every* browser can implement that logic without breaking compatibility with its earlier versions.

Additionally, I think you could solve the problem in HTML 5 by requesting a new filename attribute to <a> and a target="_download". 

Regards,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2008 13:59:27 +0000

> I don't see how Microsoft can change IE's parsing of Content-Disposition to match RFC2231 without breaking backward compatibility with itself. If they refuse to change then this change to the spec…

Oh, they can trivially. Otherwise I wouldn't even try to make progress here.

The RFC 2231 encoding can be trivially detected (as opposed to the RFC 
2047 madness), and does not overlap with what IE does today.

> Additionally, I think you could solve the problem in HTML 5 by requesting a new filename attribute to <a> and a target="_download". 

That's <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5773>, which 
reminded me to look at C-D again.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jun 2008 18:18:39 +0200

> 1) s/1806/2183/g (this is editorial, methinks)

Done in <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/269>.

> use UTF-8 encoding in producers.

and 4)

Copy over more of RFC2183, for instance "disposition=inline" (which I 
think the major browsers understand).

An alternative to all this would be to throw out Content-Disposition, 
and move it ("C-D as used as HTTP header") into a separate spec. If we 
did that, would we want to make at a WG work item?

BR, Julian