Internet Engineering Task Force (IETF) L. Masinter
Request for Comments: 7578 Adobe
Obsoletes: 2388 July 2015
Category: Standards Track
ISSN: 2070-1721
Returning Values from Forms: multipart/form-data
Abstract
This specification defines the multipart/form-data media type, which
can be used by a wide variety of applications and transported by a
wide variety of protocols as a way of returning a set of values as
the result of a user filling out a form. This document obsoletes
RFC 2388.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7578.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Masinter Standards Track [Page 1]
RFC 7578 multipart/form-data July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Percent-Encoding Option . . . . . . . . . . . . . . . . . . . 3
3. Advice for Forms and Form Processing . . . . . . . . . . . . 3
4. Definition of multipart/form-data . . . . . . . . . . . . . . 4
4.1. "Boundary" Parameter of multipart/form-data . . . . . . . 4
4.2. Content-Disposition Header Field for Each Part . . . . . 4
4.3. Multiple Files for One Form Field . . . . . . . . . . . . 5
4.4. Content-Type Header Field for Each Part . . . . . . . . . 5
4.5. The Charset Parameter for "text/plain" Form Data . . . . 5
4.6. The _charset_ Field for Default Charset . . . . . . . . . 6
4.7. Content-Transfer-Encoding Deprecated . . . . . . . . . . 6
4.8. Other "Content-" Header Fields . . . . . . . . . . . . . 7
5. Operability Considerations . . . . . . . . . . . . . . . . . 7
5.1. Non-ASCII Field Names and Values . . . . . . . . . . . . 7
5.1.1. Avoid Non-ASCII Field Names . . . . . . . . . . . . . 7
5.1.2. Interpreting Forms and Creating multipart/form-data
Data . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8
5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8
5.3. Interoperability with Web Applications . . . . . . . . . 8
5.4. Correlating Form Data with the Original Form . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Media Type Registration for multipart/form-data . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 14
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
In many applications, it is possible for a user to be presented with
a form. The user will fill out the form, including information that
is typed, generated by user input, or included from files that the
user has selected. When the form is filled out, the data from the
form is sent from the user to the receiving application.
The definition of multipart/form-data is derived from one of those
applications, originally set out in [RFC1867] and subsequently
incorporated into HTML 3.2 [W3C.REC-html32-19970114], where forms are
expressed in HTML, and the form data is sent via HTTP or electronic
mail. This representation is widely implemented in numerous web
browsers and web servers.
Masinter Standards Track [Page 2]
RFC 7578 multipart/form-data July 2015
However, multipart/form-data is also used for forms that are
presented using representations other than HTML (spreadsheets, PDF,
etc.) and for transport using means other than electronic mail or
HTTP; it is used in distributed applications that do not involve
forms at all or do not have users filling out the form. For this
reason, this document defines a general syntax and semantics
independent of the application for which it is used, with specific
rules for web applications noted in context.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Percent-Encoding Option
Within this specification, "percent-encoding" (as defined in
[RFC3986]) is offered as a possible way of encoding characters in
file names that are otherwise disallowed, including non-ASCII
characters, spaces, control characters, and so forth. The encoding
is created replacing each non-ASCII or disallowed character with a
sequence, where each byte of the UTF-8 encoding of the character is
represented by a percent-sign (%) followed by the (case-insensitive)
hexadecimal of that byte.
3. Advice for Forms and Form Processing
The representation and interpretation of forms and the nature of form
processing is not specified by this document. However, for forms and
form processing that result in the generation of multipart/form-data,
some suggestions are included.
In a form, there is generally a sequence of fields, where each field
is expected to be supplied with a value, e.g., by a user who fills
out the form. Each field has a name. After a form has been filled
out and the form's data is "submitted", the form processing results
in a set of values for each field -- the "form data".
In forms that work with multipart/form-data, field names could be
arbitrary Unicode strings; however, restricting field names to ASCII
will help avoid some interoperability issues (see Section 5.1).
Within a given form, ensuring field names are unique is also helpful.
Some fields may have default values or presupplied values in the form
itself. Fields with presupplied values might be hidden or invisible;
this allows using generic processing for form data from a variety of
actual forms.
Masinter Standards Track [Page 3]
RFC 7578 multipart/form-data July 2015
4. Definition of multipart/form-data
The media type multipart/form-data follows the model of multipart
MIME data streams as specified in Section 5.1 of [RFC2046]; changes
are noted in this document.
A multipart/form-data body contains a series of parts separated by a
boundary.
4.1. "Boundary" Parameter of multipart/form-data
As with other multipart types, the parts are delimited with a
boundary delimiter, constructed using CRLF, "--", and the value of
the "boundary" parameter. The boundary is supplied as a "boundary"
parameter to the multipart/form-data type. As noted in Section 5.1
of [RFC2046], the boundary delimiter MUST NOT appear inside any of
the encapsulated parts, and it is often necessary to enclose the
"boundary" parameter values in quotes in the Content-Type header
field.
4.2. Content-Disposition Header Field for Each Part
Each part MUST contain a Content-Disposition header field [RFC2183]
where the disposition type is "form-data". The Content-Disposition
header field MUST also contain an additional parameter of "name"; the
value of the "name" parameter is the original field name from the
form (possibly encoded; see Section 5.1). For example, a part might
contain a header field such as the following, with the body of the
part containing the form data of the "user" field:
Content-Disposition: form-data; name="user"
For form data that represents the content of a file, a name for the
file SHOULD be supplied as well, by using a "filename" parameter of
the Content-Disposition header field. The file name isn't mandatory
for cases where the file name isn't available or is meaningless or
private; this might result, for example, when selection or drag-and-
drop is used or when the form data content is streamed directly from
a device.
If a "filename" parameter is supplied, the requirements of
Section 2.3 of [RFC2183] for the "receiving MUA" (i.e., the receiving
Mail User Agent) apply to receivers of multipart/form-data as well:
do not use the file name blindly, check and possibly change to match
local file system conventions if applicable, and do not use directory
path information that may be present.
Masinter Standards Track [Page 4]
RFC 7578 multipart/form-data July 2015
In most multipart types, the MIME header fields in each part are
restricted to US-ASCII; for compatibility with those systems, file
names normally visible to users MAY be encoded using the percent-
encoding method in Section 2, following how a "file:" URI
[URI-SCHEME] might be encoded.
NOTE: The encoding method described in [RFC5987], which would add a
"filename*" parameter to the Content-Disposition header field, MUST
NOT be used.
Some commonly deployed systems use multipart/form-data with file
names directly encoded including octets outside the US-ASCII range.
The encoding used for the file names is typically UTF-8, although
HTML forms will use the charset associated with the form.
4.3. Multiple Files for One Form Field
The form data for a form field might include multiple files.
[RFC2388] suggested that multiple files for a single form field be
transmitted using a nested "multipart/mixed" part. This usage is
deprecated.
To match widely deployed implementations, multiple files MUST be sent
by supplying each file in a separate part but all with the same
"name" parameter.
Receiving applications intended for wide applicability (e.g.,
multipart/form-data parsing libraries) SHOULD also support the older
method of supplying multiple files.
4.4. Content-Type Header Field for Each Part
Each part MAY have an (optional) "Content-Type" header field, which
defaults to "text/plain". If the contents of a file are to be sent,
the file data SHOULD be labeled with an appropriate media type, if
known, or "application/octet-stream".
4.5. The Charset Parameter for "text/plain" Form Data
In the case where the form data is text, the charset parameter for
the "text/plain" Content-Type MAY be used to indicate the character
encoding used in that part. For example, a form with a text field in
which a user typed "Joe owes