As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending appliction and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".






 
RFC 2388                  multipart/form-data                August 1998


4.2 Sets of files

   If the value of a form field is a set of files rather than a single
   file, that value can be transferred together using the
   "multipart/mixed" format.

4.3 Encoding

   While the HTTP protocol can transport arbitrary binary data, the
   default for mail transport is the 7BIT encoding.  The value supplied
   for a part may need to be encoded and the "content-transfer-encoding"
   header supplied if the value does not conform to the default
   encoding.  [See section 5 of RFC 2046 for more details.]

4.4 Other attributes

   Forms may request file inputs from the user; the form software may
   include the file name and other file attributes, as specified in [RFC
   2184].

   The original local file name may be supplied as well, either as a
   "filename" parameter either of the "content-disposition: form-data"
   header or, in the case of multiple files, in a "content-disposition:
   file" header of the subpart. The sending application MAY supply a
   file name; if the file name of the sender's operating system is not
   in US-ASCII, the file name might be approximated, or encoded using
   the method of RFC 2231.

   This is a convenience for those cases where the files supplied by the
   form might contain references to each other, e.g., a TeX file and its
   .sty auxiliary style description.

4.5 Charset of text in form data

   Each part of a multipart/form-data is supposed to have a content-
   type.  In the case where a field element is text, the charset
   parameter for the text indicates the character encoding used.

   For example, a form with a text field in which a user typed 'Joe owes
   100' where  is the Euro symbol might have form data returned
   as:

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






 
RFC 2388                  multipart/form-data                August 1998


    Joe owes =80100.
    --AaB03x

5. Operability considerations

5.1 Compression, encryption

   Some of the data in forms may be compressed or encrypted, using other
   MIME mechanisms. This is a function of the application that is
   generating the form-data.

5.2 Other data encodings rather than multipart

   Various people have suggested using new mime top-level type
   "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of
   "packet" to express indeterminate-length binary data, rather than
   relying on the multipart-style boundaries. While this would be
   useful, the "multipart" mechanisms are well established, simple to
   implement on both the sending client and receiving server, and as
   efficient as other methods of dealing with multiple combinations of
   binary data.

   The multipart/form-data encoding has a high overhead and performance
   impact if there are many fields with short values. However, in
   practice, for the forms in use, for example, in HTML, the average
   overhead is not significant.