Media subtype name:
form-data
Required parameters:
none
Optional parameters:
none
Encoding considerations:
No additional considerations other than as for other multipart types.
Published specification:
section 7 of draft-ietf-html-fileupload-02.txt, included below
Security Considerations
The multipart/form-data type introduces no new security
considerations beyond what might occur with any of the enclosed
parts.
Person & email address to contact for further information:
Larry Masinter
masinter@parc.xerox.com
================================================================
Here is section 7 of draft-ietf-html-fileupload-02.txt:
7. Registration of multipart/form-data
The media-type multipart/form-data follows the rules of all
multipart MIME data streams as outlined in RFC 1521. It is intended
for use in returning the data that comes about from filling out a
form. In a form (in HTML, although other applications may also use
forms), there are a series of fields to be supplied by the user who
fills out the form. Each field has a name. The name of the field
is restricted to be a set of US-ASCII graphic characters; within a
given form, the names are unique.
multipart/form-data contains a series of parts. Each part is expected
to contain a content-disposition header where the value is
"form-data" and a name attribute specifies the field name within the
form, e.g., 'content-disposition: form-data; name="xxxxx"', where
xxxxx is the field name corresponding to that field. As with all
multipart MIME types, each part has an optional Content-Type which
defaults to text/plain.
Note that mime headers are generally required to consist only of
7-bit data in the US-ASCII character set. This specification thus
requires that the field names used consist of 7-bit ascii US
characters.
If the contents of a file are returned via filling out a form, then
the file input is identified as application/octet-stream or the
appropriate media type, if known. If multiple files are to be
returned as the result of a single form entry, they can be returned
as multipart/mixed embedded within the multipart/form-data.
The "content-transfer-encoding" header should be supplied for all
fields whose values do not conform to the default 7BIT encoding
(all characters 7-bit US-ASCII data with lines no longer than 1000
characters.)
Otherwise, file data and longer field values may be
transferred using a content-transfer-encoding appropriate to the
protocol of the ACTION in the form. For HTTP applications,
content-transfer-encoding of "binary" may be use. If the ACTION is
a "mailto:" URL, then the user agent may encode the data
appropriately to the mail transport mechanism. [See section 5 of
RFC 1521 for more details.]
File inputs may also identify the file name. The file name may be
described using the 'filename' parameter of the
"content-disposition" header. This is not required, but is strongly
recommended in any case where the original filename is known. This
is useful or necessary in many applications.