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 RFC 1806
[35].
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
15.5 for Content-Disposition security issues.
Content-Disposition
The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in
RFC 2183 to specify the presentation style. A MIME part can have:
- an inline content-disposition, which means that it should be automatically displayed when the message is displayed, or
- an attachment content-disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.
In addition to the presentation style, the content-disposition header also provides fields for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.
The following example is taken from
RFC 2183, where the header is defined
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 February 1997 16:29:51 -0500";
The filename may be encoded as defined by
RFC 2231.
As of 2010, a good majority of
mail user agents do not follow this prescription fully. The widely used
Mozilla Thunderbird mail client makes its own decisions about which MIME parts should be automatically displayed, ignoring the
content-disposition headers in the messages. It also sends out newly composed messages with
inline content-disposition for all MIME parts. Most users are unaware of how to set the content-disposition to
attachment.
[4] Many mail user agents also send messages with the file name in the
name parameter of the
content-type header instead of the
filename parameter of the
content-disposition header. This practice is discouraged.
[5]