rfc7578v3.txt   rfc7578.txt 
Internet Engineering Task Force (IETF) L. Masinter Internet Engineering Task Force (IETF) L. Masinter
Request for Comments: 7578 Adobe Request for Comments: 7578 Adobe
Obsoletes: 2388 June 2015 Obsoletes: 2388 July 2015
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
Returning Values from Forms: multipart/form-data Returning Values from Forms: multipart/form-data
Abstract Abstract
This specification defines the multipart/form-data media type, which This specification defines the multipart/form-data media type, which
can be used by a wide variety of applications and transported by a 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 wide variety of protocols as a way of returning a set of values as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 13
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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
skipping to change at page 8, line 19 skipping to change at page 8, line 19
5.1.3. Parsing and Interpreting Form Data 5.1.3. Parsing and Interpreting Form Data
While this specification provides guidance for the creation of While this specification provides guidance for the creation of
multipart/form-data, parsers and interpreters should be aware of the multipart/form-data, parsers and interpreters should be aware of the
variety of implementations. File systems differ as to whether and variety of implementations. File systems differ as to whether and
how they normalize Unicode names, for example. The matching of form how they normalize Unicode names, for example. The matching of form
elements to form-data parts may rely on a fuzzier match. In elements to form-data parts may rely on a fuzzier match. In
particular, some multipart/form-data generators might have followed particular, some multipart/form-data generators might have followed
the previous advice of [RFC2388] and used the "encoded-word" method the previous advice of [RFC2388] and used the "encoded-word" method
of encoding non-ASCII values, as described in [RFC2047] (using ABNF of encoding non-ASCII values, as described in [RFC2047]:
[RFC5234] syntax):
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 to send 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 field is not parameter of a 'text/plain' Content-Type header field is not
skipping to change at page 9, line 6 skipping to change at page 8, line 52
Many web applications use the 'application/x-www-form-urlencoded' Many web applications use the 'application/x-www-form-urlencoded'
method for returning data from forms. This format is quite compact, method for returning data from forms. This format is quite compact,
for example: 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 a 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 the 'application/x-www- application might also need to support the 'application/x-www-form-
form-urlencoded' format. 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
skipping to change at page 12, line 21 skipping to change at page 12, line 21
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, DOI 10.17487/RFC2231, November Continuations", RFC 2231, DOI 10.17487/RFC2231, November
1997, <http://www.rfc-editor.org/info/rfc2231>. 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, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
9.2. Informative References 9.2. Informative References
[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, DOI 10.17487/RFC1867, November 1995, HTML", RFC 1867, DOI 10.17487/RFC1867, November 1995,
<http://www.rfc-editor.org/info/rfc1867>. <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, DOI 10.17487/RFC2388, August 1998, form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
<http://www.rfc-editor.org/info/rfc2388>. <http://www.rfc-editor.org/info/rfc2388>.
skipping to change at page 15, line 12 skipping to change at page 14, line 18
Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry
Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as
well as others, including Ian Hickson, who requested it be produced well as others, including Ian Hickson, who requested it be produced
in the first place. 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. 7 change blocks. 
15 lines changed or deleted 9 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/