rfc7578.original   rfc7578.txt 
APPSAWG L. Masinter Internet Engineering Task Force (IETF) L. Masinter
Internet-Draft Adobe Request for Comments: 7578 Adobe
Obsoletes: 2388 (if approved) April 10, 2015 Obsoletes: 2388 July 2015
Intended status: Standards Track Category: Standards Track
Expires: October 12, 2015 ISSN: 2070-1721
Returning Values from Forms: multipart/form-data Returning Values from Forms: multipart/form-data
draft-ietf-appsawg-multipart-form-data-11
Abstract Abstract
This specification defines the multipart/form-data Internet Media This specification defines the multipart/form-data media type, which
Type, which can be used by a wide variety of applications and can be used by a wide variety of applications and transported by a
transported by a wide variety of protocols as a way of returning a wide variety of protocols as a way of returning a set of values as
set of values as the result of a user filling out a form. It the result of a user filling out a form. This document obsoletes RFC
obsoletes RFC 2388. 2388.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 12, 2015. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. percent-encoding option . . . . . . . . . . . . . . . . . . . 3 2. Percent-Encoding Option . . . . . . . . . . . . . . . . . . . 3
3. Advice for Forms and Form Processing . . . . . . . . . . . . 3 3. Advice for Forms and Form Processing . . . . . . . . . . . . 3
4. Definition of multipart/form-data . . . . . . . . . . . . . . 4 4. Definition of multipart/form-data . . . . . . . . . . . . . . 4
4.1. Boundary parameter of multipart/form-data . . . . . . . . 4 4.1. "Boundary" Parameter of multipart/form-data . . . . . . . 4
4.2. Content-Disposition header for each part . . . . . . . . 4 4.2. Content-Disposition Header Field for Each Part . . . . . 4
4.3. filename attribute of content-distribution part header . 4 4.3. Multiple Files for One Form Field . . . . . . . . . . . . 5
4.4. Multiple files for one form field . . . . . . . . . . . . 5 4.4. Content-Type Header Field for Each Part . . . . . . . . . 5
4.5. Content-Type header for each part . . . . . . . . . . . . 5 4.5. The Charset Parameter for 'text/plain' Form Data . . . . 5
4.6. The charset parameter for text/plain form data . . . . . 5 4.6. The _charset_ Field for Default Charset . . . . . . . . . 6
4.7. The _charset_ field for default charset . . . . . . . . . 6 4.7. Content-Transfer-Encoding Deprecated . . . . . . . . . . 6
4.8. Content-Transfer-Encoding deprecated . . . . . . . . . . 6 4.8. Other "Content-" Header Fields . . . . . . . . . . . . . 7
4.9. Other Content- headers . . . . . . . . . . . . . . . . . 7 5. Operability Considerations . . . . . . . . . . . . . . . . . 7
5. Operability considerations . . . . . . . . . . . . . . . . . 7 5.1. Non-ASCII Field Names and Values . . . . . . . . . . . . 7
5.1. Non-ASCII field names and values . . . . . . . . . . . . 7 5.1.1. Avoid Non-ASCII Field Names . . . . . . . . . . . . . 7
5.1.1. Avoid non-ASCII field names . . . . . . . . . . . . . 7 5.1.2. Interpreting Forms and Creating multipart/form-data
5.1.2. Interpreting forms and creating form-data . . . . . . 7 Data . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Parsing and interpreting form data . . . . . . . . . 8 5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8
5.2. Ordered fields and duplicated field names . . . . . . . . 8 5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8
5.3. Interoperability with web applications . . . . . . . . . 8 5.3. Interoperability with Web Applications . . . . . . . . . 8
5.4. Correlating form data with the original form . . . . . . 9 5.4. Correlating Form Data with the Original Form . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Media type registration for multipart/form-data . . . . . . . 10 8. Media Type Registration for multipart/form-data . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 12 Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 13
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In many applications, it is possible for a user to be presented with 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 a form. The user will fill out the form, including information that
is typed, generated by user input, or included from files that the 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 user has selected. When the form is filled out, the data from the
form is sent from the user to the receiving application. form is sent from the user to the receiving application.
The definition of "multipart/form-data" is derived from one of those The definition of multipart/form-data is derived from one of those
applications, originally set out in [RFC1867] and subsequently applications, originally set out in [RFC1867] and subsequently
incorporated into HTML 3.2 [W3C.REC-html32-19970114], where forms are incorporated into HTML 3.2 [W3C.REC-html32-19970114], where forms are
expressed in HTML, and in which the form data is sent via HTTP or expressed in HTML, and the form data is sent via HTTP or electronic
electronic mail. This representation is widely implemented in mail. This representation is widely implemented in numerous web
numerous web browsers and web servers. browsers and web servers.
However, "multipart/form-data" is also used for forms that are However, multipart/form-data is also used for forms that are
presented using representations other than HTML (spreadsheets, PDF, presented using representations other than HTML (spreadsheets, PDF,
etc.), and for transport using means other than electronic mail or etc.) and for transport using means other than electronic mail or
HTTP; it is used in distributed applications which do not involve 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 forms at all or do not have users filling out the form. For this
reason, this document defines a general syntax and semantics reason, this document defines a general syntax and semantics
independent of the application for which it is used, with specific independent of the application for which it is used, with specific
rules for web applications noted in context. rules for web applications noted in context.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. percent-encoding option 2. Percent-Encoding Option
Within this specification, "percent-encoding" (as defined in Within this specification, "percent-encoding" (as defined in
[RFC3986]) is offered as a possible way of encoding characters in [RFC3986]) is offered as a possible way of encoding characters in
file names that are otherwise disallowed, including non-ASCII file names that are otherwise disallowed, including non-ASCII
characters, spaces, control characters and so forth. The encoding is characters, spaces, control characters, and so forth. The encoding
created replacing each non-ASCII or disallowed character with a is created replacing each non-ASCII or disallowed character with a
sequence, where each byte of the UTF-8 encoding of the character is sequence, where each byte of the UTF-8 encoding of the character is
represented by a percent-sign (%) followed by the (case-insensitive) represented by a percent-sign (%) followed by the (case-insensitive)
hexadecimal of that byte. hexadecimal of that byte.
3. Advice for Forms and Form Processing 3. Advice for Forms and Form Processing
The representation and interpretation of forms and the nature of form The representation and interpretation of forms and the nature of form
processing is not specified by this document. However, for forms and processing is not specified by this document. However, for forms and
form-processing that result in generation of multipart/form-data, form processing that result in the generation of multipart/form-data,
some suggestions are included. some suggestions are included.
In a form, there is generally a sequence of fields, where each field 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 is expected to be supplied with a value, e.g., by a user who fills
the form. Each field has a name. After a form has been filled out, out the form. Each field has a name. After a form has been filled
and the form's data is "submitted": the form processing results in a out and the form's data is "submitted", the form processing results
set of values for each field-- the "form data". in a set of values for each field -- the "form data".
In forms that work with multipart/form-data, field names could be In forms that work with multipart/form-data, field names could be
arbitrary Unicode strings; however, restricting field names to ASCII arbitrary Unicode strings; however, restricting field names to ASCII
will help avoid some interoperability issues (see Section 5.1). will help avoid some interoperability issues (see Section 5.1).
Within a given form, ensuring field names are unique is also helpful. Within a given form, ensuring field names are unique is also helpful.
Some fields may have default values or presupplied values in the form Some fields may have default values or presupplied values in the form
itself. Fields with presupplied values might be hidden or invisible; itself. Fields with presupplied values might be hidden or invisible;
this allows using generic processing for form data from a variety of this allows using generic processing for form data from a variety of
actual forms. actual forms.
4. Definition of multipart/form-data 4. Definition of multipart/form-data
The media-type "multipart/form-data" follows the model of multipart The media type multipart/form-data follows the model of multipart
MIME data streams as specified in [RFC2046] Section 5.1; changes are MIME data streams as specified in Section 5.1 of [RFC2046]; changes
noted in this document. are noted in this document.
A "multipart/form-data" body contains a series of parts, separated by A multipart/form-data body contains a series of parts separated by a
a boundary. boundary.
4.1. Boundary parameter of multipart/form-data 4.1. "Boundary" Parameter of multipart/form-data
As with other multipart types, the parts are delimited with a As with other multipart types, the parts are delimited with a
boundary delimiter, constructed using CRLF, "--", the value of the boundary delimiter, constructed using CRLF, "--", and the value of
boundary parameter. The boundary is supplied as a "boundary" the "boundary" parameter. The boundary is supplied as a "boundary"
parameter to the "multipart/form-data" type. As noted in [RFC2046] parameter to the multipart/form-data type. As noted in Section 5.1
Section 5.1, the boundary delimiter MUST NOT appear inside any of the of [RFC2046], the boundary delimiter MUST NOT appear inside any of
encapsulated parts, and it is often necessary to enclose the boundary the encapsulated parts, and it is often necessary to enclose the
parameter values in quotes on the Content-type line. "boundary" parameter values in quotes in the Content-Type header
field.
4.2. Content-Disposition header for each part 4.2. Content-Disposition Header Field for Each Part
Each part MUST contain a "content-disposition" header [RFC2183] and Each part MUST contain a Content-Disposition header field [RFC2183]
where the disposition type is "form-data". The "content-disposition" where the disposition type is "form-data". The Content-Disposition
header MUST also contain an additional parameter of "name"; the value header field MUST also contain an additional parameter of "name"; the
of the "name" parameter is the original field name from the form value of the "name" parameter is the original field name from the
(possibly encoded; see Section 5.1). For example, a part might form (possibly encoded; see Section 5.1). For example, a part might
contain a header: 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" Content-Disposition: form-data; name="user"
with the body of the part containing the form data of the "user"
field.
4.3. filename attribute of content-distribution part header
For form data that represents the content of a file, a name for the 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 file SHOULD be supplied as well, by using a "filename" parameter of
the "content-disposition" header. The file name isn't mandatory for the Content-Disposition header field. The file name isn't mandatory
cases where the file name isn't available or is meaningless or for cases where the file name isn't available or is meaningless or
private; this might result, for example, from selection or drag-and- private; this might result, for example, when selection or drag-and-
drop or where the form data content is streamed directly from a drop is used or when the form data content is streamed directly from
device. a device.
If a filename parameter is supplied, the requirements of [RFC2183] If a "filename" parameter is supplied, the requirements of
Section 2.3 for "receiving MUA" apply to recievers of "multipart/ Section 2.3 of [RFC2183] for the "receiving MUA" (i.e., the receiving
form-data" as well: Do not use the file name blindly, check and Mail User Agent) apply to receivers of multipart/form-data as well:
possibly change to match local filesystem conventions if applicable, do not use the file name blindly, check and possibly change to match
do not use directory path information that may be present. local file system conventions if applicable, and do not use directory
path information that may be present.
In most multipart types, the MIME headers in each part are restricted In most multipart types, the MIME header fields in each part are
to US-ASCII; for compatibility with those systems, file names restricted to US-ASCII; for compatibility with those systems, file
normally visible to users MAY be encoded using the percent-encoding names normally visible to users MAY be encoded using the percent-
method in Section 2, following how a "file:" URI encoding method in Section 2, following how a "file:" URI
[I-D.ietf-appsawg-file-scheme] might be encoded. [URI-SCHEME] might be encoded.
NOTE: The encoding method described in [RFC5987], which would add a NOTE: The encoding method described in [RFC5987], which would add a
"filename*" paramter to the "Content-Disposition" header, MUST NOT be "filename*" parameter to the Content-Disposition header field, MUST
used. NOT be used.
Some commonly deployed systems use multipart/form-data with file Some commonly deployed systems use multipart/form-data with file
names directly encoded including octets outside the US-ASCII range. names directly encoded including octets outside the US-ASCII range.
The encoding used for the file names is typically UTF-8, although The encoding used for the file names is typically UTF-8, although
HTML forms will use the charset associated with the form. HTML forms will use the charset associated with the form.
4.4. Multiple files for one form field 4.3. Multiple Files for One Form Field
The form data for a form field might include multiple files. The form data for a form field might include multiple files.
[RFC2388] suggested that multiple files for a single form field be [RFC2388] suggested that multiple files for a single form field be
transmitted using a nested multipart/mixed part. This usage is transmitted using a nested 'multipart/mixed' part. This usage is
deprecated. deprecated.
To match widely deployed implementations, multiple files MUST be sent To match widely deployed implementations, multiple files MUST be sent
by supplying each file in a separate part, but all with the same by supplying each file in a separate part but all with the same
"name" parameter. "name" parameter.
Receiving applications intended for wide applicability (e.g. Receiving applications intended for wide applicability (e.g.,
multipart/form-data parsing libraries) SHOULD also support the older multipart/form-data parsing libraries) SHOULD also support the older
method of supplying multiple files. method of supplying multiple files.
4.5. Content-Type header for each part 4.4. Content-Type Header Field for Each Part
Each part MAY have an (optional) "content-type", which defaults to Each part MAY have an (optional) "Content-Type" header field, which
"text/plain". If the contents of a file are to be sent, the file defaults to 'text/plain'. If the contents of a file are to be sent,
data SHOULD be labeled with an appropriate media type, if known, or the file data SHOULD be labeled with an appropriate media type, if
"application/octet-stream". known, or 'application/octet-stream'.
4.6. The charset parameter for text/plain form data 4.5. The Charset Parameter for 'text/plain' Form Data
In the case where the form data is text, the charset parameter for 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 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 encoding used in that part. For example, a form with a text field in
which a user typed "Joe owes <eu>100" where <eu> is the Euro symbol which a user typed "Joe owes <eu>100", where <eu> is the Euro symbol,
might have form data returned as: might have form data returned as:
--AaB03x --AaB03x
content-disposition: form-data; name="field1" content-disposition: form-data; name="field1"
content-type: text/plain;charset=UTF-8 content-type: text/plain;charset=UTF-8
content-transfer-encoding: quoted-printable content-transfer-encoding: quoted-printable
Joe owes =E2=82=AC100. Joe owes =E2=82=AC100.
--AaB03x --AaB03x
In practice, many widely deployed implementations do not supply a In practice, many widely deployed implementations do not supply a
charset parameter in each part, but, rather, they rely on the notion charset parameter in each part, but rather, they rely on the notion
of a "default charset" for a multipart/form-data instance. of a "default charset" for a multipart/form-data instance.
Subsequent sections will explain how the default charset is Subsequent sections will explain how the default charset is
established. established.
4.7. The _charset_ field for default charset 4.6. The _charset_ Field for Default Charset
Some form processing applications (including HTML) have the Some form-processing applications (including HTML) have the
convention that the value of a form entry with entry name "_charset_" convention that the value of a form entry with entry name "_charset_"
and type "hidden" is automatically set when the form is opened; the and type "hidden" is automatically set when the form is opened; the
value is used as the default charset of text field values (see form- value is used as the default charset of text field values (see form-
charset in Section 5.1.2). In such cases, the value of the default charset in Section 5.1.2). In such cases, the value of the default
charset for each text/plain part without a charset parameter is the charset for each 'text/plain' part without a charset parameter is the
supplied value. For example: supplied value. For example:
--AaB03x --AaB03x
content-disposition: form-data; name="_charset_" content-disposition: form-data; name="_charset_"
iso-8859-1 iso-8859-1
--AaB03x-- --AaB03x--
content-disposition: form-data; name="field1" content-disposition: form-data; name="field1"
...text encoded in iso-8859-1 ... ...text encoded in iso-8859-1 ...
AaB03x-- AaB03x--
4.8. Content-Transfer-Encoding deprecated 4.7. Content-Transfer-Encoding Deprecated
Previously, it was recommended that senders use a "Content-Transfer- Previously, it was recommended that senders use a Content-Transfer-
Encoding" encoding (such as "quoted-printable") for each non-ASCII Encoding encoding (such as "quoted-printable") for each non-ASCII
part of a multipart/form-data body, because that would allow use in part of a multipart/form-data body because that would allow use in
transports that only support a "7BIT" encoding. This use is transports that only support a "7bit" encoding. This use is
deprecated for use in contexts that support binary data such as HTTP. deprecated for use in contexts that support binary data such as HTTP.
Senders SHOULD NOT generate any parts with a "Content-Transfer- Senders SHOULD NOT generate any parts with a Content-Transfer-
Encoding" header. Encoding header field.
Currently, no deployed implementations that send such bodies have Currently, no deployed implementations that send such bodies have
been discovered. been discovered.
4.9. Other Content- headers 4.8. Other "Content-" Header Fields
The "multipart/form-data" media type does not support any MIME The multipart/form-data media type does not support any MIME header
headers in the parts other than Content-Type, Content-Disposition, fields in parts other than Content-Type, Content-Disposition, and (in
and (in limited circumstances) Content-Transfer-Encoding. Other limited circumstances) Content-Transfer-Encoding. Other header
headers MUST NOT be included and MUST be ignored. fields MUST NOT be included and MUST be ignored.
5. Operability considerations 5. Operability Considerations
5.1. Non-ASCII field names and values 5.1. Non-ASCII Field Names and Values
Normally, MIME headers in multipart bodies are required to consist Normally, MIME header fields in multipart bodies are required to
only of 7-bit data in the US-ASCII character set. While [RFC2388] consist only of 7-bit data in the US-ASCII character set. While
suggested that non-ASCII field names be encoded according to the [RFC2388] suggested that non-ASCII field names be encoded according
method in [RFC2047], this practice doesn't seem to have been followed to the method in [RFC2047], this practice doesn't seem to have been
widely. followed widely.
This specification makes three sets of recommendations for three This specification makes three sets of recommendations for three
different states of workflow. different states of workflow.
5.1.1. Avoid non-ASCII field names 5.1.1. Avoid Non-ASCII Field Names
For broadest interoperability with existing deployed software, those For broadest interoperability with existing deployed software, those
creating forms SHOULD avoid non-ASCII field names. This should not creating forms SHOULD avoid non-ASCII field names. This should not
be a burden, because in general the field names are not visible to be a burden because, in general, the field names are not visible to
users. The field names in the underlying need not match what the users. The field names in the underlying need not match what the
user sees on the screen. user sees on the screen.
If non-ASCII field names are unavoidable, form or application If non-ASCII field names are unavoidable, form or application
creators SHOULD use UTF-8 uniformly. This will minimize creators SHOULD use UTF-8 uniformly. This will minimize
interoperability problems. interoperability problems.
5.1.2. Interpreting forms and creating form-data 5.1.2. Interpreting Forms and Creating multipart/form-data Data
Some applications of this specification will supply a character Some applications of this specification will supply a character
encoding to be used for interpretation of the multipart/form-data encoding to be used for interpretation of the multipart/form-data
body. In particular, HTML 5 [W3C.REC-html5-20141028] uses: body. In particular, HTML 5 [W3C.REC-html5-20141028] uses
o The content of a '_charset_' field, if there is one. o the content of a "_charset_" field, if there is one;
o the value of an accept-charset attribute of the <form> element, if o the value of an accept-charset attribute of the <form> element, if
there is one, there is one;
o the character encoding of the document containing the form, if it o the character encoding of the document containing the form, if it
is US-ASCII compatible, is US-ASCII compatible;
o otherwise UTF-8. o otherwise, UTF-8.
Call this value the form-charset. Any text, whether field name, Call this value the form-charset. Any text, whether field name,
field value, or (text/plain) form data which is uses characters field value, or ('text/plain') form data that uses characters outside
outside the ASCII range MAY be represented directly encoded in the the ASCII range MAY be represented directly encoded in the form-
form-charset. charset.
5.1.3. Parsing and interpreting form data 5.1.3. Parsing and Interpreting Form Data
While this specification provides guidance for creation of multipart/ While this specification provides guidance for the creation of
form-data, parsers and interpreters should be aware of the variety of multipart/form-data, parsers and interpreters should be aware of the
implementations. File systems differ as to whether and how they variety of implementations. File systems differ as to whether and
normalize Unicode names, for example. The matching of form elements how they normalize Unicode names, for example. The matching of form
to form-data parts may rely on a fuzzier match. In particular, some elements to form-data parts may rely on a fuzzier match. In
multipart/form-data generators might have followed the previous particular, some multipart/form-data generators might have followed
advice of [RFC2388] and used the [RFC2047] "encoded-word" method of the previous advice of [RFC2388] and used the "encoded-word" method
encoding non-ASCII values: of encoding non-ASCII values, as described in [RFC2047]:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
Others have been known to follow [RFC2231], to send unencoded UTF-8, Others have been known to follow [RFC2231], to send unencoded UTF-8,
or even strings encoded in the form-charset. or even to send strings encoded in the form-charset.
For this reason, interpreting "multipart/form-data" (even from For this reason, interpreting multipart/form-data (even from
conforming generators) may require knowing the charset used in form conforming generators) may require knowing the charset used in form
encoding, in cases where the _charset_ field value or a charset encoding in cases where the _charset_ field value or a charset
parameter of a text/plain Content-Type header is not supplied. parameter of a 'text/plain' Content-Type header field is not
supplied.
5.2. Ordered fields and duplicated field names 5.2. Ordered Fields and Duplicated Field Names
Form processors given forms with a well-defined ordering SHOULD send Form processors given forms with a well-defined ordering SHOULD send
back results in order (note that there are some forms which do not back results in order. (Note that there are some forms that do not
define a natural order.) Intermediaries MUST NOT reorder the define a natural order.) Intermediaries MUST NOT reorder the
results. Form parts with identical field names MUST NOT be results. Form parts with identical field names MUST NOT be
coalesced. coalesced.
5.3. Interoperability with web applications 5.3. Interoperability with Web Applications
Many web applications use the "application/x-url-encoded" method for Many web applications use the 'application/x-www-form-urlencoded'
returning data from forms. This format is quite compact, e.g.: method for returning data from forms. This format is quite compact,
for example:
name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
However, there is no opportunity to label the enclosed data with However, there is no opportunity to label the enclosed data with a
content type, apply a charset, or use other encoding mechanisms. content type, apply a charset, or use other encoding mechanisms.
Many form-interpreting programs (primarily web browsers) now Many form-interpreting programs (primarily web browsers) now
implement and generate multipart/form-data, but an existing implement and generate multipart/form-data, but a receiving
application might need to optionally support both the application/x- application might also need to support the
url-encoded format as well. 'application/x-www-form-urlencoded' format.
5.4. Correlating form data with the original form 5.4. Correlating Form Data with the Original Form
This specification provides no specific mechanism by which multipart/ This specification provides no specific mechanism by which multipart/
form-data can be associated with the form that caused it to be form-data can be associated with the form that caused it to be
transmitted. This separation is intentional; many different forms transmitted. This separation is intentional; many different forms
might be used for transmitting the same data. In practice, might be used for transmitting the same data. In practice,
applications may supply a specific form processing resource (in HTML, applications may supply a specific form processing resource (in HTML,
the ACTION attribute in a FORM tag) for each different form. the ACTION attribute in a FORM tag) for each different form.
Alternatively, data about the form might be encoded in a "hidden Alternatively, data about the form might be encoded in a "hidden
field" (a field which is part of the form but which has a fixed value field" (a field that is part of the form but that has a fixed value
to be transmitted back to the form-data processor.) to be transmitted back to the form-data processor).
6. IANA Considerations 6. IANA Considerations
Please update the Internet Media Type registration of multipart/form- The media type registration of multipart/form-data has been updated
data to point to this document, using the template in Section 8. In to point to this document, using the template in Section 8. In
addition, please update the registrations of the "name" parameter and addition, the registrations of the "name" parameter and the "form-
the "form-data" value in the "Content Disposition Values and data" value in the "Content Disposition Values and Parameters"
Parameters" registry to both point to this document. registry have been updated to both point to this document.
7. Security Considerations 7. Security Considerations
All form processing software should treat user supplied form-data All form-processing software should treat user supplied form-data
with sensitivity, as it often contains confidential or personally with sensitivity, as it often contains confidential or personally
identifying information. There is widespread use of form "auto-fill" identifying information. There is widespread use of form "auto-fill"
features in web browsers; these might be used to trick users to features in web browsers; these might be used to trick users to
unknowingly send confidential information when completing otherwise unknowingly send confidential information when completing otherwise
innoccuous tasks. Multipart/form-data does not supply any features innocuous tasks. multipart/form-data does not supply any features
for checking integrity, ensuring confidentiality, avoiding user for checking integrity, ensuring confidentiality, avoiding user
confusion, or other security features; those concerns must be confusion, or other security features; those concerns must be
addressed by the form-filling and form-data-interpreting addressed by the form-filling and form-data-interpreting
applications. applications.
Applications which receive forms and process them must be careful not Applications that receive forms and process them must be careful not
to supply data back to the requesting form processing site that was to supply data back to the requesting form-processing site that was
not intended to be sent. not intended to be sent.
It is important when interpreting the filename of the Content- It is important when interpreting the filename of the Content-
Disposition header to not overwrite files in the recipient's file Disposition header field to not inadvertently overwrite files in the
space inadvertently. recipient's file space.
User applications that request form information from users must be User applications that request form information from users must be
careful not to cause a user to send information to the requestor or a careful not to cause a user to send information to the requestor or a
third party unwillingly or unwittingly. For example, a form might third party unwillingly or unwittingly. For example, a form might
request 'spam' information to be sent to an unintended third party, request that spam information be sent to an unintended third party or
or private information to be sent to someone that the user might not private information be sent to someone that the user might not
actually intend. While this is primarily an issue for the actually intend. While this is primarily an issue for the
representation and interpretation of forms themselves (rather than representation and interpretation of forms themselves (rather than
the data representation of the form data), the transportation of the data representation of the form data), the transportation of
private information must be done in a way that does not expose it to private information must be done in a way that does not expose it to
unwanted prying. unwanted prying.
With the introduction of form-data that can reasonably send back the With the introduction of form-data that can reasonably send back the
content of files from a user's file space, the possibility arises content of files from a user's file space, the possibility arises
that a user might be sent an automated script that fills out a form that a user might be sent an automated script that fills out a form
and then sends one of the user's local files to another address. and then sends one of the user's local files to another address.
Thus, additional caution is required when executing automated Thus, additional caution is required when executing automated
scripting where form-data might include a user's files. scripting where form-data might include a user's files.
Files sent via multipart/form-data may contain arbitrary executable Files sent via multipart/form-data may contain arbitrary executable
content, and precautions against malicious content are necessary. content, and precautions against malicious content are necessary.
The considerations of [RFC2183] Sections 2.3 and 5 with respect to The considerations of Sections 2.3 and 5 of [RFC2183], with respect
the filename parameter of the Content-Disposition header also apply to the "filename" parameter of the Content-Disposition header field,
to its usage here. also apply to its usage here.
8. Media type registration for multipart/form-data 8. Media Type Registration for multipart/form-data
This section is the [RFC6838] media type registration. This section is the media type registration using the template from
[RFC6838].
Type name: multipart Type name: multipart
Subtype name: form-data Subtype name: form-data
Required parameters: boundary Required parameters: boundary
Optional parameters: none Optional parameters: none
Encoding considerations: Common use is BINARY. Encoding considerations: Common use is BINARY.
In limited use (or transports that restrict the encoding to 7BIT In limited use (or transports that restrict the encoding to 7bit
or 8BIT each part is encoded separately using Content-Transfer- or 8bit), each part is encoded separately using Content-Transfer-
Encoding Section 4.8. Encoding; see Section 4.7.
Security considerations: See Section 7 of this document. Security considerations: See Section 7 of this document.
Interoperability considerations: This document makes several Interoperability considerations: This document makes several
recommendations for interoperability with deployed recommendations for interoperability with deployed
implementations, including Section 4.8. implementations, including Section 4.7.
Published specification: This document. Published specification: This document.
Applications that use this media type: Numerous web browsers, Applications that use this media type: Numerous web browsers,
servers, and web applications. servers, and web applications.
Fragment identifier considerations: None: Fragment identifiers are Fragment identifier considerations: None; fragment identifiers are
not defined for this type. not defined for this type.
Additional information: None: no deprecated alias names, magic Additional information:
numbers, file extensions or Macintosh ssssfile type codes.
Person & email address to contact for further information Additional information:
Author of this document.
Intended Usage: COMMON Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: Author of
this document.
Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Author of this document. Author: Author of this document.
Change controller: IETF Change controller: IETF
Provisional registration: N/A Provisional registration: N/A
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046, DOI
November 1996. 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, DOI 10.17487/RFC2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, DOI 10.17487/
RFC2183, August 1997,
<http://www.rfc-editor.org/info/rfc2183>.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Word Extensions: Character Sets, Languages, and
Character Sets, Languages, and Continuations", RFC 2231, Continuations", RFC 2231, DOI 10.17487/RFC2231, November
November 1997. 1997, <http://www.rfc-editor.org/info/rfc2231>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-appsawg-file-scheme]
Kerwin, M., "The file URI Scheme", draft-ietf-appsawg-
file-scheme-00 (work in progress), January 2015.
[RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in [RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in
HTML", RFC 1867, November 1995. HTML", RFC 1867, DOI 10.17487/RFC1867, November 1995,
<http://www.rfc-editor.org/info/rfc1867>.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
<http://www.rfc-editor.org/info/rfc2388>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010,
<http://www.rfc-editor.org/info/rfc5987>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013. 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[URI-SCHEME]
Kerwin, M., "The file URI Scheme", Work in Progress,
draft-ietf-appsawg-file-scheme-00, January 2015.
[W3C.REC-html32-19970114] [W3C.REC-html32-19970114]
Raggett, D., "HTML 3.2 Reference Specification", World Raggett, D., "HTML 3.2 Reference Specification", W3C
Wide Web Consortium Recommendation REC-html32-19970114, Recommendation REC-html32-19970114, January 1997,
January 1997, <http://www.w3.org/TR/REC-html32-19970114>. <http://www.w3.org/TR/REC-html32-19970114>.
[W3C.REC-html5-20141028] [W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, E., and S. Pfeiffer, "HTML5", Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
World Wide Web Consortium Recommendation REC- Recommendation REC-html5-20141028, October 2014,
html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>. <http://www.w3.org/TR/2014/REC-html5-20141028>.
Appendix A. Changes from RFC 2388 Appendix A. Changes from RFC 2388
The handling of non-ASCII field names changed-- no longer The handling of non-ASCII field names has changed -- the method
recommending the RFC 2047 method, instead suggesting senders send described in RFC 2047 is no longer recommended; instead, it is
UTF-8 field names directly, and file names directly in the form- suggested that senders send UTF-8 field names directly and that file
charset. names be sent directly in the form-charset.
The handling of multiple files submitted as the result of a single The handling of multiple files submitted as the result of a single
form field (e.g. HTML's <input type=file multiple> element) results form field (e.g., HTML's <input type=file multiple> element) results
in each file having its own top level part with the same name in each file having its own top-level part with the same name
parameter; the method of using a nested "multipart/mixed" from parameter; the method of using a nested 'multipart/mixed' from
[RFC2388] is no longer recommended for creators, and not required for [RFC2388] is no longer recommended for creators and is not required
receivers as there are no known implementations of senders. for receivers as there are no known implementations of senders.
The _charset_ convention and use of an explicit form-data charset is
documented.
'boundary' is a required parameter in Content-Type. The _charset_ convention and use of an explicit "form-data" charset
is documented; also, "boundary" is now a required parameter in
Content-Type.
The relationship of the ordering of fields within a form and the The relationship of the ordering of fields within a form and the
ordering of returned values within multipart/form-data was not ordering of returned values within multipart/form-data was not
defined before, nor was the handling of the case where a form has defined before, nor was the handling of the case where a form has
multiple fields with the same name. multiple fields with the same name.
Editorial: Removed obsolete discussion of alternatives in appendix. Various editorial changes were made; they include removing the
Update references. Move outline of form processing into obsolete discussion of alternatives from the appendix, updating the
Introduction. references, and moving the outline of form processing into the
introduction.
Appendix B. Alternatives Appendix B. Alternatives
There are numerous alternative ways in which form data can be There are numerous alternative ways in which form data can be
encoded; many are listed in [RFC2388] section 5.2. The multipart/ encoded; many are listed in Section 5.2 of [RFC2388]. The multipart/
form-data encoding is verbose, especially if there are many fields form-data encoding is verbose, especially if there are many fields
with short values. In most use cases, this overhead isn't with short values. In most use cases, this overhead isn't
significant. significant.
More problematic are the differences introduced when implementors More problematic are the differences introduced when implementors
opted to not follow [RFC2388] when encoding non-ASCII field names opted to not follow [RFC2388] when encoding non-ASCII field names
(perhaps because "may" should have been "MUST"). As a result, (perhaps because "may" should have been "MUST"). As a result,
parsers need to be more complex for matching against the possible parsers need to be more complex for matching against the possible
outputs of various encoding methods. outputs of various encoding methods.
Acknowledgements
Many thanks to the those who reviewed this document -- Alexey
Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry
Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as
well as others, including Ian Hickson, who requested it be produced
in the first place.
Author's Address Author's Address
Larry Masinter Larry Masinter
Adobe Adobe
Email: masinter@adobe.com Email: masinter@adobe.com
URI: http://larry.masinter.net URI: http://larry.masinter.net
 End of changes. 109 change blocks. 
242 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/