Summary

  • RFC 7578 keeps same-name form parts separate and forbids intermediaries from reordering results. A convenient scalar representation can therefore discard meaning that the wire format preserved.
  • Larry Masinter's work on successive multipart specifications also leaves a firm boundary: a field name, a client filename and permission to use a file are different things.

Imagine an application asking for two supporting documents under one upload field. Two files arrive, each in a separate part with the same field name. A helper converts the submission into a dictionary that retains only the last value. The request may have travelled without corruption; one document has nevertheless disappeared from the application record. This is an illustrative failure mechanism, not a reported incident or a finding about a particular library. It makes visible the problem running through Larry Masinter's multipart standards: receiving bytes and retaining their meaning are separate achievements.

A file becomes part of a form

The November 1995 RFC 1867, coauthored by E. Nebel and L. Masinter, proposed form-based file upload when ordinary HTML forms could not uniformly ask users to submit local files. It combined a file-selection extension with a MIME-compatible submission format and a migration proposal for older browsers. It was explicitly Experimental, not an Internet standard. This distinction matters: the document opened a route for implementation and discussion, rather than certifying that the whole web had already converged.

Masinter's August 1998 RFC 2388 described multipart/form-data on the Standards Track. The July 2015 RFC 7578, also bearing his name, replaced it after public review and IETF approval. Its status records community consensus; the author credit is not a warrant to assign every browser behaviour or MIME invention to one person. Masinter's dated personal home page supplies historical standards context and a public portrait, not evidence of his employment today.

The representation is a body containing a series of parts separated by a boundary. Each part identifies its original field through the name parameter of a form-data Content-Disposition header. This organisation can carry text and files together. RFC 7578 deliberately defines semantics beyond HTML, HTTP and even applications with a person filling in a form. Its importance is consequently broader than the familiar browser upload button: separate values can cross a software boundary without first being squeezed into one undifferentiated object.

The revision that refused to merge

The most revealing comparison is between two small passages. RFC 2388's section 5.5 left the relationship between form order and returned order, and the handling of duplicate field names, undefined. The 2015 specification made that contract sharper. When a form has a well-defined order, processors should return its results in order; intermediaries must not reorder them; parts with identical field names must not be coalesced. The first is a SHOULD, not an unconditional requirement for every conceivable form to possess an order. The latter prohibitions protect distinctions already present in the submission.

Multiplicity is not necessarily an error. Section 4.3 requires several files belonging to one field to be sent as separate parts with the same name. It deprecates the older nested multipart/mixed arrangement in favour of widely deployed practice, while recommending that broadly applicable receivers also support the older arrangement. That combination is the work of maintaining a deployed standard: specify a clearer outgoing representation without pretending that old inputs instantly vanish.

The dictionary example identifies where an implementation can undo this work. A scalar map may be appropriate after an application has deliberately checked cardinality and selected an interpretation. Used prematurely, it hides whether one or several parts arrived. A sequence or a representation retaining multiple values can preserve that evidence; neither automatically makes the values legitimate. Preserving a duplicate is not the same as accepting it as an authorised instruction.

Names do not confer authority

A field name says which field the part belongs to. A filename is separate metadata. RFC 7578 recommends supplying one for file content but permits its absence when it is unavailable, meaningless or private. A receiver must not blindly treat a supplied filename as a local storage command or retain directory path information. A device stream need not acquire a fictitious name merely to resemble a desktop file.

Character handling adds another compatibility boundary. The specification advises ASCII field names for broad interoperability, or uniform UTF-8 when non-ASCII names cannot be avoided. It documents default-charset conventions and warns that older generators have used different encodings. It also prohibits the filename* parameter in this format. These provisions are not interchangeable with a general rule borrowed from another HTTP header context. The document records the behaviour it is trying to make interoperable, rather than promising that one decoding guess works everywhere.

Finally, the body contains no built-in mechanism associating it with its originating form. An application may use its processing destination or hidden data to establish context, but the representation itself does not authenticate that context. Nor does multipart provide confidentiality or integrity. RFC 1867 already warned against sending local files the user had not explicitly requested; RFC 7578 discusses unintended disclosure, overwriting files and executable content. A structurally valid submission has crossed none of those trust boundaries merely by being parsed.

Sources and limits

This account compares the three linked RFCs and the dated first-party page. It does not measure contemporary deployment, audit libraries or establish an incident rate. The operational implications are editorial deductions from the documented distinctions. The public reference headshot grounds the AI editorial portrait; its generated workspace is illustrative, not Masinter's documented office.