RFC 6266 / START HERE
HTTP Content-Disposition, before the details
HTTP means Hypertext Transfer Protocol. Content-Disposition names a response header for handling information and an optional suggested filename.
It tells recipient software whether to process a response normally or offer a local save interaction. Filename parameters suggest a name, including an extended form for international characters.
The idea in one picture
Send response metadata
Read the suggested name
Apply recipient policy
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
RFC6266 gives this widely deployed HTTP field a defined profile, clarifies filename encoding and warns about unsafe local interpretation. It updates the older HTTP definition in RFC 2616; MIME body-part headers are outside its scope.
A familiar example
A report service sends attachment with a name containing a euro sign. The browser can offer a save using an international filename and a fallback for older software. The suggested name cannot authorize an overwrite or prove the downloaded content safe.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Choose normal processing or a save interactionContent-Disposition adds response-processing information. attachment suggests a local save interaction; inline keeps normal processing according to the media type.→
- Parse parameters without splitting inside quotesA disposition token is followed by semicolon-separated parameters. A quoted string can contain characters that would otherwise separate syntax.→
- Encode an international filename and provide a fallbackfilename* uses an extended character-encoding form. UTF-8 bytes and percent escapes can carry a name such as € rates without guessing the header encoding.→
- Treat the filename as an untrusted suggestionA response cannot grant permission to write outside authorized locations. Filename paths, extensions, controls and special names need recipient-side handling.→
- Handle extensions and invalid fields within the right scopeUnknown parameters can be ignored without losing understood information. An invalid field is different from an invalid response, and this HTTP profile does not define MIME body-part handling.→
This introduction explains RFC 6266 (2011). Read the original RFC ↗