Keep multiple files as separate parts
03One field can contain several files. Repeating its name on separate parts preserves those files instead of flattening them into one value.
Combining the two parts into one value or reversing them at an intermediary would violate the preservation rules. The valid ordered pair remains visible; no transformed delivery is drawn.
Key idea: Multiple files for one field MUST use separate parts with the same name parameter.
Rules & examples
Multiple files for one field MUST use separate parts with the same name parameter.
- The example photos field has two small fictional text files, one.txt and two.txt. Each file has its own top-level part, filename and text/plain Content-Type, with name="photos" on both parts.
- RFC 2388 suggested nested multipart/mixed for this case. RFC 7578 deprecates that sending method. Receiving libraries intended for wide applicability SHOULD also support the older method; this is not a blanket MUST-reject rule.
- Form processors given a well-defined form order SHOULD send results in that order. Intermediaries MUST NOT reorder the results. These are different requirement levels for different actors.
- Parts with identical field names MUST NOT be coalesced. A receiver should preserve the separate values rather than discard one through a single-value dictionary. This does not define an application framework’s array-key syntax.
- The ordered list [one.txt, two.txt] is explanatory receiver state. Brackets and array indices are not transmitted as extra field-name characters in the example.
This chapter covers both repeated file values and the general duplicate-name rule. It models a flat list of parts; nested legacy multipart parsing is not implemented. The two fixture files are not real uploads.
Sources
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Nested multipart/mixed sending is deprecated. Each file MUST have a separate part with the same name. Broadly applicable receiving libraries SHOULD also support the older method.
Read the updated RFC section ↗