Returning Values from Forms: multipart/form-data
obsoletes
- rfc-2388 — Returning Values from Forms: multipart/form-data
Extracted elements (25)
Non-ASCII field names SHOULD be avoided for broadest interoperability, since field names are generally not visible to users and need not match the labels shown on screen. If non-ASCII is unavoidable, UTF-8 SHOULD be used uniformly.
RFC 5987's 'filename*' parameter encoding was explicitly prohibited (MUST NOT) rather than merely deprecated, because its use would create a conflicting encoding path alongside percent-encoding; the goal is to limit the diversity of filename encoding schemes that parsers must handle.
The nested 'multipart/mixed' method for multiple files per field (from RFC 2388) was deprecated because no known sender implementations exist, and the simpler approach of repeated top-level parts with the same 'name' parameter matches all widely deployed implementations.
The specification provides no mechanism to associate a multipart/form-data submission with the specific form that generated it; this separation is intentional, as many different forms might transmit the same data structure. Applications use ACTION URIs or hidden fields for correlation instead.
Many web applications use 'application/x-www-form-urlencoded' for form data and a receiving application may need to support both that format and multipart/form-data. The URL-encoded format is more compact but cannot label parts with a Content-Type or charset.
Parsers must handle diverse non-ASCII encoding practices from deployed generators: RFC 2047 encoded-words (as recommended by RFC 2388), RFC 2231, unencoded UTF-8, or form-charset-encoded strings. No single method dominates in practice.
Each part MUST contain a Content-Disposition header field with disposition type 'form-data'. The Content-Disposition header field MUST also contain an additional 'name' parameter whose value is the original field name from the form.
Form processors given forms with a well-defined ordering SHOULD send back results in that order. Intermediaries MUST NOT reorder the results. Form parts with identical field names MUST NOT be coalesced.
MIME header fields other than Content-Type, Content-Disposition, and (in limited circumstances) Content-Transfer-Encoding MUST NOT be included in parts and MUST be ignored by receivers.
Multiple files for a single form field MUST be sent by supplying each file in a separate part, all with the same 'name' parameter. The previously recommended nested 'multipart/mixed' approach from RFC 2388 is deprecated for creators.
Receiving applications intended for wide applicability SHOULD also support the older nested 'multipart/mixed' method of supplying multiple files, for backward compatibility with RFC 2388 generators.
Senders SHOULD NOT generate any parts with a Content-Transfer-Encoding header field. Use of Content-Transfer-Encoding (e.g., 'quoted-printable') for non-ASCII parts is deprecated in binary-capable transports such as HTTP.
The boundary delimiter MUST NOT appear inside any of the encapsulated parts. The boundary is supplied as a required 'boundary' parameter to the multipart/form-data Content-Type header field.
The RFC 5987 'filename*' parameter encoding MUST NOT be used in the Content-Disposition header field of multipart/form-data parts. File names MAY instead be percent-encoded following the method described in Section 2.
A form field with entry name '_charset_' and type 'hidden' may carry the default charset for all 'text/plain' parts that lack an explicit charset parameter. HTML 5 recognizes this convention as the primary source for the form-charset.
Each part MAY have an optional Content-Type header field, which defaults to 'text/plain'. If file contents are being sent, the file data SHOULD be labeled with an appropriate media type, or 'application/octet-stream' if unknown.
For parts representing file content, a 'filename' parameter SHOULD be supplied in the Content-Disposition header field. Receivers must not use the filename blindly: check it against local file system conventions and discard any directory path information present.
multipart/form-data is a MIME multipart media type used to return a set of values from a filled-out form. It consists of a series of parts separated by a boundary delimiter, following the multipart model of RFC 2046 Section 5.1.
The charset parameter of a 'text/plain' Content-Type MAY be used to indicate the character encoding of a text part. Many deployed implementations omit per-part charset and rely instead on a form-level default charset.
The IANA media type registration for multipart/form-data has been updated to reference this document. The registrations of the 'name' parameter and the 'form-data' disposition value in the Content Disposition Values and Parameters registry are also updated to point here.
Automated scripts that fill out forms could send local user files to unintended third parties. Files sent via multipart/form-data may contain arbitrary executable content; precautions against malicious content are necessary.
Form-processing software should treat user-supplied form data with sensitivity as it often contains confidential or personally identifying information. Browser auto-fill features could be exploited to trick users into unknowingly submitting confidential information.
User applications that request form data must not cause users to send information to requestors or third parties unwillingly or unwittingly. The transportation of private information must not expose it to unwanted prying.
When interpreting the 'filename' parameter of the Content-Disposition header field, receivers must not inadvertently overwrite files in their file space, and must discard any directory path information present in the filename.
The multipart/form-data body is encoded as BINARY in common use. The 'boundary' parameter is required in the Content-Type header. Each part is delimited by CRLF + '--' + boundary value, with a closing delimiter of CRLF + '--' + boundary + '--'.