Summary

  • RFC 1867 and RFC 2388 described several files from one form field as a nested multipart/mixed part inside multipart/form-data.
  • RFC 7578 later said that no implementations of that sending method were known, replaced it for senders with one top-level part per file, and kept receiver support for the older nesting as a compatibility measure.

A file picker needed a wire format

Before HTML forms could submit local file contents through a common browser mechanism, a server often needed a custom client. RFC 1867 proposed an INPUT TYPE=FILE control and a MIME representation that could carry both ordinary fields and file bytes. The idea travelled with an important caveat: the document was Experimental, not a finished Internet Standard, and its compatibility plan still imagined user agents that could not perform the new upload.

For a single selected file, the form could send one part. For several files selected for one field, RFC 1867 drew a second multipart body inside the first: the outer multipart/form-data identified the form field; the inner multipart/mixed carried the files. The container was intelligible on paper. Each nesting level had a job.

RFC 2388, published as Standards Track in 1998, separated the media type from HTML and HTTP. A spreadsheet or another application could use it too. Yet its rule for a field containing a set of files preserved the nested multipart/mixed arrangement. The 1995 proposal had become a reusable specification, and one detail of its example had become the prescribed shape.

The wire image did not follow the diagram

RFC 7578, which obsoleted RFC 2388 in 2015, records the discrepancy unusually plainly. It says the nested method was deprecated for creators and was not required of receivers because there were no known implementations of senders. To match implementations, the new rule gives each file its own top-level form-data part; parts for one form control repeat the same name parameter.

That is a change in where the grouping lives. Under the old design, one named part contained a nested list of files. Under the replacement, the outer sequence contains several parts bearing the same field name. The new specification did not claim that nested MIME had become syntactically impossible. It kept a recommendation for broadly useful receivers to accept the old form. The sender recommendation changed; compatibility at the receiving edge remained.

The authors' phrase “no known implementations” is evidence of what RFC 7578's revision could identify, not a census proving that no sender ever emitted the old structure. It gives no vendor, browser share, first-use date, or failure rate. It does establish that a standards document revised a data shape because its successors could not point to a sending implementation for the shape the previous RFC described.

A standard also had to say what a sequence meant

The revision repaired a second ambiguity. RFC 2388 left the relationship between form order and returned-part order unspecified, and did not define what happened when field names were repeated. RFC 7578 says a processor should preserve an ordering when the form defines one, intermediaries must not reorder the results, and parts with identical names must not be coalesced. Those instructions make repeated names usable as repeated values rather than an accidental collision.

It is tempting to summarize the change as a move from “MIME nesting” to “flat data.” That is too broad. MIME still supplies the part structure, and some forms have no natural order. The specific correction was narrower: a multi-file form control is represented by multiple peer parts, with the shared field name carrying their association. The enclosing request, the form's intended order, each part's bytes, and the receiving application's interpretation remain distinct.

Running code as evidence, not slogan

Heng Lu's essay on running-code primacy argues that Internet coordination should take implemented behavior seriously rather than treating text alone as reality. RFC 2388 offers a modest, unusually legible example: RFC 7578 did not preserve every earlier recommendation for its own sake. Its authors altered the multi-file encoding to match the sender behavior they could identify, while retaining a compatibility path for receivers.

That does not show that implementers always get a protocol right or that a standard should simply ratify whatever software happens to do. The document supplies no account of who made the change first, how many systems were involved, or which operational costs drove it. What the record supports is a two-sided rulemaking discipline: specify a wire shape, look for the actors that actually emit it, and preserve a way to read the old shape when deployed data may still contain it.

Sources