Percent-encoding (RFC 3986 Section 2.1) was rejected for the filename parameter because the character encoding used for decoding varies unpredictably across user agents based on page encoding, locale, and configuration, making it practically impossible to use reliably.

http

RFC 2047 encoded-word encoding was rejected for the filename parameter because the RFC 2047 specification explicitly prohibits its use in Content-Disposition parameters, and in practice implementations vary widely between fully implementing it, ignoring it, or displaying the raw encoded string to users.

http

RFC 2616 limited the 'filename' parameter to the quoted-string form only. RFC 6266 also allows the token form to match actual implementations, since restricting to quoted-string would be an exceptional parameter syntax inconsistent with how the field is actually used.

http

RFC 2616 restricted the 'attachment' disposition type to 'application/octet-stream' content. RFC 6266 removes this restriction because recipients in practice never check the content type for this purpose, and the restriction discouraged proper media type declarations.

http

RFC 5987 encoding was chosen as the sole internationalization mechanism for the 'filename*' parameter because it is the only IETF-standardized, interoperable solution; encoding-sniffing heuristics (switching to UTF-8 when it 'looks like' UTF-8) are non-interoperable and risk misinterpreting actual ISO-8859-1 values.

http

Many user agent implementations predating RFC 6266 do not understand the 'filename*' parameter. Senders should include both 'filename' (as fallback) and 'filename*' (for full Unicode support), placing 'filename' first due to parsing problems in some implementations that ignore 'filename*' when it appears after 'filename'.

http

Many user agents do not properly handle the escape character '\' in quoted-string filename values, and some erroneously perform percent-decoding, potentially misinterpreting filenames containing '%' followed by two hex digits.

http

The IANA registry for disposition values and parameters (RFC 2183, Section 9) is shared across protocols including MIME and HTTP; not all registered disposition parameters (e.g., 'creation-date', 'modification-date', 'size') are applicable in the HTTP context.

http, registry

Recipients MAY take steps to recover a usable field value from an invalid Content-Disposition header, but SHOULD NOT reject the message outright unless it is a validator. The default handling of invalid fields is to ignore them.

http

Recipients MUST NOT allow the server-supplied filename to cause writes to any location other than one to which the recipient is specifically entitled; path segments (delimited by '\' and '/') MUST be stripped to prevent directory traversal attacks.

http, security

Recipients SHOULD ignore or substitute filenames with names that have special meaning in the file system or shell commands, such as '.', '..', '~', '|', and device names.

http, security

Recipients SHOULD ignore unrecognized Content-Disposition parameters to enable future extensibility, consistent with RFC 2183 Section 2.8.

http

Recipients SHOULD strip or replace character sequences that cause confusion in user interfaces and filenames, including control characters and leading/trailing whitespace.

http, security

Recipients that use file extensions to determine media type MUST ensure that a safe file extension is used, optimally matching the media type of the received payload, to prevent privilege escalation when the saved file is later opened.

http, security

Senders MUST NOT generate Content-Disposition header fields that are invalid (per the ABNF grammar or prose requirements in Section 4).

http

Unknown or unhandled disposition types SHOULD be handled by recipients the same way as 'attachment', prompting the user to save the payload rather than process it inline.

http

When both 'filename' and 'filename*' are present in a single header field value, recipients SHOULD pick 'filename*' and ignore 'filename', allowing senders to provide a fallback for legacy agents while still conveying the full Unicode filename.

http

The Content-Disposition response header field conveys additional information about how to process the response payload, including an optional filename suggestion for local storage. It consists of a disposition type optionally followed by semicolon-delimited parameters.

http

Two filename parameters are defined: 'filename' uses token or quoted-string form limited to ISO-8859-1, while 'filename*' uses the RFC 5987 ext-value encoding, allowing characters outside ISO-8859-1 and optional language tagging.

http

Two standard disposition types are defined: 'attachment' (case-insensitive) indicates the recipient should prompt the user to save the response locally; 'inline' (case-insensitive) implies default processing according to media type.

http

This document updates the permanent HTTP header field registry (RFC 3864) with a standard-status entry for 'Content-Disposition', applicable protocol 'http', with IETF as author/change controller and this specification (Section 4) as the defining document.

http, registry

Trusting the server-provided file extension could introduce privilege escalation when the saved file is later opened by the operating system. Recipients should validate that the extension safely matches the received media type rather than blindly using the server-supplied name.

http, security

Using server-supplied information for constructing local filenames introduces risks including directory traversal (writing outside the intended location), privilege escalation via dangerous file extensions (e.g., '.exe'), and confusion from special characters or reserved filesystem names.

http, security

Content-Disposition = 'Content-Disposition' ':' disposition-type *( ';' disposition-parm). Disposition-parm includes 'filename' '=' value (token or quoted-string) and 'filename*' '=' ext-value (RFC 5987 encoding). Multiple instances of the same parameter name are invalid.

http