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

Content-Disposition (new issue?)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 20 Jun 2008 11:58:29 +0200
Message-ID: <485B7F45.3090804@gmx.de>
To: ietf-http-wg@w3.org

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
Received on Friday, 20 June 2008 09:59:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:48 GMT