Returning Values from Forms: multipart/form-data
obsoleted by
- rfc-7578 — Returning Values from Forms: multipart/form-data
Extracted elements (21)
Despite high overhead for forms with many short-value fields, multipart/form-data is justified because in practice (e.g., HTML forms) the average overhead is not significant, and the format supports content-type labeling and charset encoding that application/x-www-form-urlencoded cannot.
The multipart/form-data encoding was chosen over proposed alternatives such as a new 'aggregate' MIME top-level type or a 'packet' content-transfer-encoding because multipart mechanisms are well established, simple to implement on both client and server, and as efficient as other methods.
The specification intentionally provides no mechanism to correlate multipart/form-data with the originating form, because many different forms might transmit the same data. Applications may use a specific ACTION URL or hidden fields for this purpose.
Many web applications use 'application/x-www-form-urlencoded' for form data, which is more compact but provides no opportunity to label data with content type, apply a charset, or use other encoding mechanisms. Applications may need to support both formats.
The ordering of fields within a form and the ordering of returned values in multipart/form-data is not defined by this specification; nor is handling of multiple fields with the same name. Intermediaries SHOULD NOT reorder results.
A boundary MUST be selected that does not occur in any of the data. Each field is sent as a part in the order defined by the sending application and form.
Each part has an optional Content-Type, which defaults to text/plain. File inputs should use the appropriate media type if known, or 'application/octet-stream' if unknown.
Each part of a multipart/form-data message MUST contain a Content-Disposition header with disposition type 'form-data' and a 'name' parameter whose value is the original field name in the form.
Each part SHOULD be labelled with an appropriate Content-Type if the media type is known (e.g., inferred from file extension or OS type information) or as 'application/octet-stream'.
Field names containing characters outside US-ASCII SHOULD be encoded using the method in RFC 2047, because MIME headers are generally required to consist only of 7-bit US-ASCII data.
If multiple files are returned as the result of a single form entry, they SHOULD be represented as a 'multipart/mixed' part embedded within the multipart/form-data.
If the value of a part does not conform to the default encoding, the part may need to be encoded and a 'content-transfer-encoding' header supplied. For mail transport, the default is 7BIT encoding.
The sending application MAY supply a file name via the 'filename' parameter in the Content-Disposition header. If the sender's OS filename is not in US-ASCII, it might be approximated or encoded using RFC 2231.
For file inputs, the original local file name may be supplied as a 'filename' parameter in 'content-disposition: form-data', or in a 'content-disposition: file' header of the subpart when multiple files are submitted.
For text fields, the charset parameter of Content-Type indicates the character encoding used. For example, 'content-type: text/plain;charset=windows-1250' with quoted-printable encoding for non-ASCII text.
multipart/form-data is a MIME media type for returning a set of form field values. It follows all multipart MIME rules from RFC 2046 and contains a series of parts, each corresponding to a named form field.
This document registers the media type 'multipart/form-data' with required parameters: none; optional parameters: none. Encoding considerations follow those for other multipart MIME types.
The introduction of form-data that can send back file contents from a user's file system creates risk from automated scripts that fill out forms and transmit local files to a remote address. Additional caution is required when executing automated scripting involving multipart/form-data.
User applications requesting form information must ensure users do not send information unwillingly or unwittingly to the requestor or a third party. A form could be crafted to send spam or private information to unintended parties.
When interpreting Content-Disposition, implementations must not inadvertently overwrite files in the recipient's address space. The 'filename' parameter in particular must be treated carefully to prevent path traversal attacks.
The Content-Disposition header for each part takes the form: 'Content-Disposition: form-data; name="fieldname"'. The 'name' parameter carries the original HTML/form field name and is required for each part.