Summary

  • RFC 1806 added inline, attachment and an optional filename to MIME, but described them as desired presentation and a suggested archival name—not a command or receipt.
  • The receiving agent retained the decisions that matter locally: whether to display, where to store, how to avoid collision, which extension is safe and whether later opening requires explicit action.
  • RFC 2183, RFC 2231, RFC 6266 and RFC 7578 carried the vocabulary into richer metadata, international names, HTTP downloads and uploads without transferring authority over the recipient's filesystem.

MIME could carry a part before it could say what should happen next

Internet mail became a container before it became a presentation agreement. RFC 1521 let one message carry typed text, images, applications and nested multipart structures. Its later replacements, RFC 2045 and RFC 2046, refined the grammar and the media types. A receiver could discover what a part claimed to be and where its encoded bytes ended.

That did not settle what the person should see. One mail program might expand every image in the reading pane. Another might display a list of files. A character terminal could not imitate a graphical workstation. The message structure supplied material; presentation still belonged to the receiving user agent.

RFC 1806, published as an Experimental specification in June 1995, addressed precisely that gap. It introduced an optional Content-Disposition header for any MIME entity. The sender could tag a part with desired presentation semantics. If the field was absent, the mail user agent remained free to choose whatever method it considered suitable.

That absence rule exposes the architecture. The header did not create the receiver's authority. It gave the receiver one more statement to consider. The receiving program still had the screen, local policy, filesystem and user relationship. A field arriving inside a message could influence those controls; it could not own them.

Two dispositions allocated the next action

The first vocabulary was deliberately small. inline meant that a body part should be shown automatically in the ordinary flow, subject to the containing multipart's rules. attachment meant that display should not happen automatically. Some further action from the user should come first. A graphical program might show an icon; a text terminal might show a selectable list.

This was a useful allocation of decision-making. The sender knew whether a part belonged to the immediate document or was a separate object. The receiver knew what it could safely render and how its interface worked. The user decided whether to cross the attachment gate.

But a disposition value was not an observation. inline did not prove that a client supported the media type, passed its safety checks, rendered the bytes or placed them in front of a human. attachment did not prove that a person opened or saved anything. Even a standards-compliant receiver could suppress an inline part or quarantine an attachment for reasons outside the field.

Nested multipart structure made the limit clearer. A disposition on a multipart entity applied to that container as a whole. If the container was an attachment, its presentation waited for user action. Only after the container was opened did the dispositions of its inner parts become relevant. One message could therefore carry several successive gates. No outer label proved that an inner part had been reached.

Unknown values were handled conservatively. RFC 1806 directed an unrecognized disposition type to be treated as attachment, on the theory that a sender using an elaborate new type probably intended more than ordinary inline display. Unrecognized parameters could be ignored. The fallback bounded automatic exposure; it did not invent semantics for a token the receiver did not understand.

A filename crossed the network but not the namespace boundary

The optional filename parameter supplied what RFC 1806 called a default archival disposition. If the recipient chose to detach a body part, the value could suggest what the external file should be called.

The word “suggest” carried most of the security model. A filename that is harmless on one system can be a path, device, startup instruction or executable trigger on another. The receiver, not the sender, knows which names already exist, which directories are writable, which separators are meaningful and which applications will interpret an extension.

RFC 1806 therefore said that directory information should not be respected. A value that looked like a path was to be reduced to a terminal component. The receiving program had to avoid overwriting an existing file and adapt the name to local conventions. The field could be present on an inline entity without causing a file write at all; it merely supplied a name if the user later chose to save it.

The specification's security section did not hide behind general warnings. It named the hazards: creating a startup file, overwriting a system file, replacing an existing file, putting an executable in a command-search path, or sending content to a pipe. The general rule was that a receiving program should not name or place content so that interpretation or execution occurred without explicit user initiation.

That is a complete evidence chain in miniature. A sender emitted a string. A parser recovered it. A policy removed path meaning and checked collisions. A filesystem operation created bytes under an actual local name. A later application might open them. The header proves only the first claim and, with a capture, the second. It cannot serve as a receipt for the remaining events.

A standards-track revision preserved the limit

The RFC Series record for RFC 1806 shows that RFC 2183 replaced the experiment in August 1997 as a Proposed Standard. The revised text kept inline, attachment and receiver-owned filename checking. It added creation, modification and read dates plus an approximate size.

Those additions made a MIME entity look more like a transferable file record, but they did not authenticate its history. RFC 2183 even warned Unix and POSIX implementors that st_ctime is not creation time. A date was a sender-carried assertion. The receiver could choose whether to preserve it. Approximate size could help preallocate storage or decide whether space appeared sufficient; it was not an exact digest, a completed-write receipt or a guarantee that allocation would succeed.

The revision also formalized extension registration through IANA. The current Content Disposition registry contains the original values and later protocol-specific ones. Registration gives a token a public definition and change procedure. It does not show that a given client implements it or that the value makes sense in every protocol listed beside the shared registry.

Human names did not fit the first envelope

RFC 1806 acknowledged that its parameter grammar restricted filenames to US-ASCII. This was more than cosmetic. The suggested local name was meant for a person, yet many people could not state an ordinary filename in their own script.

RFC 2231 addressed long values, character sets and language information in MIME parameters. Numbered segments allowed a long value to be continued in order. A trailing asterisk on a parameter name signaled an extended value whose prefix named a character set and optional language, followed by percent-encoded octets.

This improved fidelity but introduced additional states worth preserving. Raw segments can be reordered or have gaps. Encoded and unencoded segments can be mixed. A charset can be unknown or invalid. A language tag can help display without changing the identity of the bytes. The final Unicode string is a decoding result, not the raw field.

More accurate transmission of a human name still does not make the name authoritative. A perfectly decoded path traversal remains a path traversal. A correctly reconstructed reserved device name remains dangerous. Encoding solves representation; it does not grant permission.

The Web borrowed the field before it standardized it

By 1999, RFC 2616 could say that the RFC 1806-derived field was often implemented in HTTP even though Content-Disposition was not part of the HTTP standard. The Web had found the same need as mail: an origin server wanted to say that a representation should be saved separately and to offer a useful name.

RFC 6266 standardized that response-header use in 2011. attachment asks the user agent to prompt for local saving rather than process the representation normally. inline describes ordinary processing and may still carry a name for a later save operation.

The HTTP profile sharpened the recipient's obligations. Filenames were “advisory only.” A user agent must prevent a server from selecting an unauthorized location, strip all but the last path segment, distrust an extension that could cause dangerous later handling, remove confusing control characters or whitespace, and neutralize names with special filesystem or shell meaning.

For names beyond the legacy range, a server can send a plain filename fallback and a filename* extended value; a recipient supporting both should prefer the latter. RFC 8187 later refined HTTP's charset-and-language parameter encoding and required UTF-8 support. The precedence decision needs its own record: raw values, selected parameter, decoder and resulting displayed name.

An upload used the same header in the other direction

Content-Disposition also lives inside multipart form bodies, but that is a separate contract. RFC 6266 expressly excludes body-part fields such as multipart/form-data from its HTTP response-header profile.

RFC 7578 requires each form-data part to carry Content-Disposition: form-data and a name parameter. A file part should include a filename when a meaningful one exists. On this path the browser or upload client is the sender; the receiving web application becomes the party defending its filesystem.

RFC 7578 repeats the old rule: do not use the supplied name blindly, adapt it to local conventions and discard directory information. It also forbids the filename* convention in this body-part context, even though HTTP responses use it. The shared field name does not erase context. A parser that applies the right grammar in the wrong protocol position can produce a plausible and still incorrect result.

The history is therefore not simply “email attachments became browser downloads.” It is the migration of a narrow authority contract. Across mail, HTTP responses and form uploads, a remote party can describe desired handling and propose a human-facing name. The local party still owns the final action.

Sources