File: rfc7578.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (837 lines) | stat: -rw-r--r-- 40,552 bytes
parent folder | download | duplicates (2)
<pre>Internet Engineering Task Force (IETF)                       L. Masinter
Request for Comments: 7578                                         Adobe
Obsoletes: <a href="./rfc2388">2388</a>                                                July 2015
Category: Standards Track
ISSN: 2070-1721


            <span class="h1">Returning Values from Forms: multipart/form-data</span>

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
   <a href="./rfc2388">RFC 2388</a>.

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7578">http://www.rfc-editor.org/info/rfc7578</a>.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.






<span class="grey">Masinter                     Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Percent-Encoding Option . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Advice for Forms and Form Processing  . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-4">4</a>.  Definition of multipart/form-data . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-4.1">4.1</a>.  "Boundary" Parameter of multipart/form-data . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-4.2">4.2</a>.  Content-Disposition Header Field for Each Part  . . . . .   <a href="#page-4">4</a>
     <a href="#section-4.3">4.3</a>.  Multiple Files for One Form Field . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-4.4">4.4</a>.  Content-Type Header Field for Each Part . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-4.5">4.5</a>.  The Charset Parameter for "text/plain" Form Data  . . . .   <a href="#page-5">5</a>
     <a href="#section-4.6">4.6</a>.  The _charset_ Field for Default Charset . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.7">4.7</a>.  Content-Transfer-Encoding Deprecated  . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.8">4.8</a>.  Other "Content-" Header Fields  . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-5">5</a>.  Operability Considerations  . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-5.1">5.1</a>.  Non-ASCII Field Names and Values  . . . . . . . . . . . .   <a href="#page-7">7</a>
       <a href="#section-5.1.1">5.1.1</a>.  Avoid Non-ASCII Field Names . . . . . . . . . . . . .   <a href="#page-7">7</a>
       5.1.2.  Interpreting Forms and Creating multipart/form-data
               Data  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
       <a href="#section-5.1.3">5.1.3</a>.  Parsing and Interpreting Form Data  . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.2">5.2</a>.  Ordered Fields and Duplicated Field Names . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.3">5.3</a>.  Interoperability with Web Applications  . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.4">5.4</a>.  Correlating Form Data with the Original Form  . . . . . .   <a href="#page-9">9</a>
   <a href="#section-6">6</a>.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-7">7</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-8">8</a>.  Media Type Registration for multipart/form-data . . . . . . .  <a href="#page-10">10</a>
   <a href="#section-9">9</a>.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-9.1">9.1</a>.  Normative References  . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-9.2">9.2</a>.  Informative References  . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#appendix-A">Appendix A</a>.  Changes from <a href="./rfc2388">RFC 2388</a>  . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
   <a href="#appendix-B">Appendix B</a>.  Alternatives . . . . . . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-15">15</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 [<a href="./rfc1867" title="&quot;Form-based File Upload in HTML&quot;">RFC1867</a>] and subsequently
   incorporated into HTML 3.2 [<a href="#ref-W3C.REC-html32-19970114">W3C.REC-html32-19970114</a>], 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.



<span class="grey">Masinter                     Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
   [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Percent-Encoding Option</span>

   Within this specification, "percent-encoding" (as defined in
   [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>]) 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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Advice for Forms and Form Processing</span>

   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 <a href="#section-5.1">Section 5.1</a>).

   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.




<span class="grey">Masinter                     Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Definition of multipart/form-data</span>

   The media type multipart/form-data follows the model of multipart
   MIME data streams as specified in <a href="./rfc2046#section-5.1">Section&nbsp;5.1 of [RFC2046]</a>; changes
   are noted in this document.

   A multipart/form-data body contains a series of parts separated by a
   boundary.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  "Boundary" Parameter of multipart/form-data</span>

   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 <a href="./rfc2046#section-5.1">Section&nbsp;5.1
   of [RFC2046]</a>, 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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Content-Disposition Header Field for Each Part</span>

   Each part MUST contain a Content-Disposition header field [<a href="./rfc2183" title="&quot;Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field&quot;">RFC2183</a>]
   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 <a href="#section-5.1">Section 5.1</a>).  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
   <a href="./rfc2183#section-2.3">Section&nbsp;2.3 of [RFC2183]</a> 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.





<span class="grey">Masinter                     Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   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 <a href="#section-2">Section 2</a>, following how a "file:" URI
   [<a href="#ref-URI-SCHEME">URI-SCHEME</a>] might be encoded.

   NOTE: The encoding method described in [<a href="./rfc5987" title="&quot;Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters&quot;">RFC5987</a>], 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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Multiple Files for One Form Field</span>

   The form data for a form field might include multiple files.

   [<a id="ref-RFC2388">RFC2388</a>] 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.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Content-Type Header Field for Each Part</span>

   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".

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  The Charset Parameter for "text/plain" Form Data</span>

   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 &lt;eu&gt;100", where &lt;eu&gt; is the Euro symbol,
   might have form data returned as:






<span class="grey">Masinter                     Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


       --AaB03x
       content-disposition: form-data; name="field1"
       content-type: text/plain;charset=UTF-8
       content-transfer-encoding: quoted-printable

       Joe owes =E2=82=AC100.
       --AaB03x

   In practice, many widely deployed implementations do not supply a
   charset parameter in each part, but rather, they rely on the notion
   of a "default charset" for a multipart/form-data instance.
   Subsequent sections will explain how the default charset is
   established.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  The _charset_ Field for Default Charset</span>

   Some form-processing applications (including HTML) have the
   convention that the value of a form entry with entry name "_charset_"
   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-
   charset in <a href="#section-5.1.2">Section 5.1.2</a>).  In such cases, the value of the default
   charset for each "text/plain" part without a charset parameter is the
   supplied value.  For example:

       --AaB03x
       content-disposition: form-data; name="_charset_"

       iso-8859-1
       --AaB03x--
       content-disposition: form-data; name="field1"

       ...text encoded in iso-8859-1 ...
       AaB03x--

<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>.  Content-Transfer-Encoding Deprecated</span>

   Previously, it was recommended that senders use a Content-Transfer-
   Encoding encoding (such as "quoted-printable") for each non-ASCII
   part of a multipart/form-data body because that would allow use in
   transports that only support a "7bit" encoding.  This use is
   deprecated for use in contexts that support binary data such as HTTP.
   Senders SHOULD NOT generate any parts with a Content-Transfer-
   Encoding header field.

   Currently, no deployed implementations that send such bodies have
   been discovered.





<span class="grey">Masinter                     Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>.  Other "Content-" Header Fields</span>

   The multipart/form-data media type does not support any MIME header
   fields in parts other than Content-Type, Content-Disposition, and (in
   limited circumstances) Content-Transfer-Encoding.  Other header
   fields MUST NOT be included and MUST be ignored.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Operability Considerations</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Non-ASCII Field Names and Values</span>

   Normally, MIME header fields in multipart bodies are required to
   consist only of 7-bit data in the US-ASCII character set.  While
   [<a href="./rfc2388" title="&quot;Returning Values from Forms: multipart/ form-data&quot;">RFC2388</a>] suggested that non-ASCII field names be encoded according
   to the method in [<a href="./rfc2047" title="&quot;MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text&quot;">RFC2047</a>], this practice doesn't seem to have been
   followed widely.

   This specification makes three sets of recommendations for three
   different states of workflow.

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Avoid Non-ASCII Field Names</span>

   For broadest interoperability with existing deployed software, those
   creating forms SHOULD avoid non-ASCII field names.  This should not
   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
   user sees on the screen.

   If non-ASCII field names are unavoidable, form or application
   creators SHOULD use UTF-8 uniformly.  This will minimize
   interoperability problems.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Interpreting Forms and Creating multipart/form-data Data</span>

   Some applications of this specification will supply a character
   encoding to be used for interpretation of the multipart/form-data
   body.  In particular, HTML 5 [<a href="#ref-W3C.REC-html5-20141028">W3C.REC-html5-20141028</a>] uses

   o  the content of a "_charset_" field, if there is one;

   o  the value of an accept-charset attribute of the &lt;form&gt; element, if
      there is one;

   o  the character encoding of the document containing the form, if it
      is US-ASCII compatible;

   o  otherwise, UTF-8.




<span class="grey">Masinter                     Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   Call this value the form-charset.  Any text, whether field name,
   field value, or ("text/plain") form data that uses characters outside
   the ASCII range MAY be represented directly encoded in the form-
   charset.

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Parsing and Interpreting Form Data</span>

   While this specification provides guidance for the creation of
   multipart/form-data, parsers and interpreters should be aware of the
   variety of implementations.  File systems differ as to whether and
   how they normalize Unicode names, for example.  The matching of form
   elements to form-data parts may rely on a fuzzier match.  In
   particular, some multipart/form-data generators might have followed
   the previous advice of [<a href="./rfc2388" title="&quot;Returning Values from Forms: multipart/ form-data&quot;">RFC2388</a>] and used the "encoded-word" method
   of encoding non-ASCII values, as described in [<a href="./rfc2047" title="&quot;MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text&quot;">RFC2047</a>]:

      encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

   Others have been known to follow [<a href="./rfc2231" title="&quot;MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations&quot;">RFC2231</a>], to send unencoded UTF-8,
   or even to send strings encoded in the form-charset.

   For this reason, interpreting multipart/form-data (even from
   conforming generators) may require knowing the charset used in form
   encoding in cases where the _charset_ field value or a charset
   parameter of a "text/plain" Content-Type header field is not
   supplied.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Ordered Fields and Duplicated Field Names</span>

   Form processors given forms with a well-defined ordering SHOULD send
   back results in order.  (Note that there are some forms that do not
   define a natural order.)  Intermediaries MUST NOT reorder the
   results.  Form parts with identical field names MUST NOT be
   coalesced.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Interoperability with Web Applications</span>

   Many web applications use the "application/x-www-form-urlencoded"
   method for returning data from forms.  This format is quite compact,
   for example:

      name=Xavier+Xantico&amp;verdict=Yes&amp;colour=Blue&amp;happy=sad&amp;Utf%F6r=Send

   However, there is no opportunity to label the enclosed data with a
   content type, apply a charset, or use other encoding mechanisms.






<span class="grey">Masinter                     Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   Many form-interpreting programs (primarily web browsers) now
   implement and generate multipart/form-data, but a receiving
   application might also need to support the
   "application/x-www-form-urlencoded" format.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Correlating Form Data with the Original Form</span>

   This specification provides no specific mechanism by which multipart/
   form-data can be associated with the form that caused it to be
   transmitted.  This separation is intentional; many different forms
   might be used for transmitting the same data.  In practice,
   applications may supply a specific form processing resource (in HTML,
   the ACTION attribute in a FORM tag) for each different form.
   Alternatively, data about the form might be encoded in a "hidden
   field" (a field that is part of the form but that has a fixed value
   to be transmitted back to the form-data processor).

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   The media type registration of multipart/form-data has been updated
   to point to this document, using the template in <a href="#section-8">Section 8</a>.  In
   addition, the registrations of the "name" parameter and the "form-
   data" value in the "Content Disposition Values and Parameters"
   registry have been updated to both point to this document.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   All form-processing software should treat user supplied form-data
   with sensitivity, as it often contains confidential or personally
   identifying information.  There is widespread use of form "auto-fill"
   features in web browsers; these might be used to trick users to
   unknowingly send confidential information when completing otherwise
   innocuous tasks.  multipart/form-data does not supply any features
   for checking integrity, ensuring confidentiality, avoiding user
   confusion, or other security features; those concerns must be
   addressed by the form-filling and form-data-interpreting
   applications.

   Applications that receive forms and process them must be careful not
   to supply data back to the requesting form-processing site that was
   not intended to be sent.

   It is important when interpreting the filename of the Content-
   Disposition header field to not inadvertently overwrite files in the
   recipient's file space.






<span class="grey">Masinter                     Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   User applications that request form information from users must be
   careful not to cause a user to send information to the requestor or a
   third party unwillingly or unwittingly.  For example, a form might
   request that spam information be sent to an unintended third party or
   private information be sent to someone that the user might not
   actually intend.  While this is primarily an issue for the
   representation and interpretation of forms themselves (rather than
   the data representation of the form data), the transportation of
   private information must be done in a way that does not expose it to
   unwanted prying.

   With the introduction of form-data that can reasonably send back the
   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
   and then sends one of the user's local files to another address.
   Thus, additional caution is required when executing automated
   scripting where form-data might include a user's files.

   Files sent via multipart/form-data may contain arbitrary executable
   content, and precautions against malicious content are necessary.

   The considerations of Sections <a href="#section-2.3">2.3</a> and <a href="#section-5">5</a> of [<a href="./rfc2183" title="&quot;Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field&quot;">RFC2183</a>], with respect
   to the "filename" parameter of the Content-Disposition header field,
   also apply to its usage here.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Media Type Registration for multipart/form-data</span>

   This section is the media type registration using the template from
   [<a href="./rfc6838" title="&quot;Media Type Specifications and Registration Procedures&quot;">RFC6838</a>].

   Type name:  multipart

   Subtype name:  form-data

   Required parameters:  boundary

   Optional parameters:  none

   Encoding considerations:  Common use is BINARY.
      In limited use (or transports that restrict the encoding to 7bit
      or 8bit), each part is encoded separately using Content-Transfer-
      Encoding; see <a href="#section-4.7">Section 4.7</a>.

   Security considerations:  See <a href="#section-7">Section 7</a> of this document.

   Interoperability considerations:  This document makes several
      recommendations for interoperability with deployed
      implementations, including <a href="#section-4.7">Section 4.7</a>.



<span class="grey">Masinter                     Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   Published specification:  This document.

   Applications that use this media type:  Numerous web browsers,
      servers, and web applications.

   Fragment identifier considerations:  None; fragment identifiers are
      not defined for this type.

   Additional information:

   Additional information:

         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 &amp; email address to contact for further information:  Author of
      this document.

   Intended usage:  COMMON

   Restrictions on usage:  none

   Author:  Author of this document.

   Change controller:  IETF

   Provisional registration:  N/A

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2046">RFC2046</a>]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", <a href="./rfc2046">RFC 2046</a>,
              DOI 10.17487/RFC2046, November 1996,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2046">http://www.rfc-editor.org/info/rfc2046</a>&gt;.

   [<a id="ref-RFC2047">RFC2047</a>]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              <a href="./rfc2047">RFC 2047</a>, DOI 10.17487/RFC2047, November 1996,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2047">http://www.rfc-editor.org/info/rfc2047</a>&gt;.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.



<span class="grey">Masinter                     Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   [<a id="ref-RFC2183">RFC2183</a>]  Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", <a href="./rfc2183">RFC 2183</a>,
              DOI 10.17487/RFC2183, August 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2183">http://www.rfc-editor.org/info/rfc2183</a>&gt;.

   [<a id="ref-RFC2231">RFC2231</a>]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", <a href="./rfc2231">RFC 2231</a>, DOI 10.17487/RFC2231, November
              1997, &lt;<a href="http://www.rfc-editor.org/info/rfc2231">http://www.rfc-editor.org/info/rfc2231</a>&gt;.

   [<a id="ref-RFC3986">RFC3986</a>]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              <a href="./rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
              &lt;<a href="http://www.rfc-editor.org/info/rfc3986">http://www.rfc-editor.org/info/rfc3986</a>&gt;.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-RFC1867">RFC1867</a>]  Nebel, E. and L. Masinter, "Form-based File Upload in
              HTML", <a href="./rfc1867">RFC 1867</a>, DOI 10.17487/RFC1867, November 1995,
              &lt;<a href="http://www.rfc-editor.org/info/rfc1867">http://www.rfc-editor.org/info/rfc1867</a>&gt;.

   [<a id="ref-RFC2388">RFC2388</a>]  Masinter, L., "Returning Values from Forms: multipart/
              form-data", <a href="./rfc2388">RFC 2388</a>, DOI 10.17487/RFC2388, August 1998,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2388">http://www.rfc-editor.org/info/rfc2388</a>&gt;.

   [<a id="ref-RFC5987">RFC5987</a>]  Reschke, J., "Character Set and Language Encoding for
              Hypertext Transfer Protocol (HTTP) Header Field
              Parameters", <a href="./rfc5987">RFC 5987</a>, DOI 10.17487/RFC5987, August 2010,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5987">http://www.rfc-editor.org/info/rfc5987</a>&gt;.

   [<a id="ref-RFC6838">RFC6838</a>]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>,
              <a href="./rfc6838">RFC 6838</a>, DOI 10.17487/RFC6838, January 2013,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6838">http://www.rfc-editor.org/info/rfc6838</a>&gt;.

   [<a id="ref-URI-SCHEME">URI-SCHEME</a>]
              Kerwin, M., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22The+file+URI+Scheme%22'>"The file URI Scheme"</a>, Work in Progress,
              <a href="./draft-ietf-appsawg-file-scheme-02">draft-ietf-appsawg-file-scheme-02</a>, May 2015.

   [<a id="ref-W3C.REC-html32-19970114">W3C.REC-html32-19970114</a>]
              Raggett, D., "HTML 3.2 Reference Specification", W3C
              Recommendation REC-html32-19970114, January 1997,
              &lt;<a href="http://www.w3.org/TR/REC-html32-19970114">http://www.w3.org/TR/REC-html32-19970114</a>&gt;.







<span class="grey">Masinter                     Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


   [<a id="ref-W3C.REC-html5-20141028">W3C.REC-html5-20141028</a>]
              Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
              Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
              Recommendation REC-html5-20141028, October 2014,
              &lt;<a href="http://www.w3.org/TR/2014/REC-html5-20141028">http://www.w3.org/TR/2014/REC-html5-20141028</a>&gt;.














































<span class="grey">Masinter                     Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Changes from <a href="./rfc2388">RFC 2388</a></span>

   The handling of non-ASCII field names has changed -- the method
   described in <a href="./rfc2047">RFC 2047</a> is no longer recommended; instead, it is
   suggested that senders send UTF-8 field names directly and that file
   names be sent directly in the form-charset.

   The handling of multiple files submitted as the result of a single
   form field (e.g., HTML's &lt;input type=file multiple&gt; element) results
   in each file having its own top-level part with the same name
   parameter; the method of using a nested "multipart/mixed" from
   [<a href="./rfc2388" title="&quot;Returning Values from Forms: multipart/ form-data&quot;">RFC2388</a>] is no longer recommended for creators and is not required
   for receivers as there are no known implementations of senders.

   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
   ordering of returned values within multipart/form-data was not
   defined before, nor was the handling of the case where a form has
   multiple fields with the same name.

   Various editorial changes were made; they include removing the
   obsolete discussion of alternatives from the appendix, updating the
   references, and moving the outline of form processing into the
   introduction.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Alternatives</span>

   There are numerous alternative ways in which form data can be
   encoded; many are listed in <a href="./rfc2388#section-5.2">Section&nbsp;5.2 of [RFC2388]</a>.  The multipart/
   form-data encoding is verbose, especially if there are many fields
   with short values.  In most use cases, this overhead isn't
   significant.

   More problematic are the differences introduced when implementors
   opted to not follow [<a href="./rfc2388" title="&quot;Returning Values from Forms: multipart/ form-data&quot;">RFC2388</a>] when encoding non-ASCII field names
   (perhaps because "may" should have been "MUST").  As a result,
   parsers need to be more complex for matching against the possible
   outputs of various encoding methods.










<span class="grey">Masinter                     Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7578">RFC 7578</a>                   multipart/form-data                 July 2015</span>


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

   Larry Masinter
   Adobe

   Email: masinter@adobe.com
   URI:   <a href="http://larry.masinter.net">http://larry.masinter.net</a>




































Masinter                     Standards Track                   [Page 15]
</pre>