Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]
This document is current and has been amended. 2 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
What it is
Content-Disposition: whether a part should be shown inline or offered as an attachment, and what to call it.
What it solves
A client could not tell an embedded image apart from a file the user is meant to save.
What it means to operate
Filename handling is the sharp edge. Filenames with non-ASCII characters need RFC 2231 encoding, and getting it wrong produces either a mangled name or, in older clients, a security problem.
Header analyser parses a real message and says what each header is claiming. Open header analyser
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
2 The Content-Disposition Header Field
- MUSTquoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used
- SHOULDNOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) parameter value containing only non-`tspecials' characters SHOULD be represented as a single `token'.
- SHOULDA short parameter value containing only ASCII characters, but including `tspecials' characters, SHOULD be represented as `quoted-string'.
- MUSTParameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].
2.3 The Filename Parameter
- SHOULDThe suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below).
- SHOULD NOTThe receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.
2.4 The Creation-Date parameter
- MAYThe creation-date parameter MAY be used to indicate the date at which the file was created.
- MUSTIf this parameter is included, the paramter value MUST be a quoted-string which contains a representation of the creation date of the file in [RFC 822] `date-time' format.
2.5 The Modification-Date parameter
- MAYThe modification-date parameter MAY be used to indicate the date at which the file was last modified.
- MUSTIf the modification-date parameter is included, the paramter value MUST be a quoted-string which contains a representation of the last modification date of the file in [RFC 822] `date-time' format.
2.6 The Read-Date parameter
- MAYThe read-date parameter MAY be used to indicate the date at which the file was last read.
- MUSTIf the read-date parameter is included, the parameter value MUST be a quoted-string which contains a representation of the last-read date of the file in [RFC 822] `date- time' format.