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:
The original definition of this type is contained in Internet Draft
draft-ietf-html-fileupload-01.txt, which has been approved by the
HTML working group to release as an RFC. However, the specification
of multipart/form-data is contained fully herein:
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 of which has
a "Name:" header. As with all multipart MIME types, each part has
an optional Content-Type which defaults to text/plain.
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 optionally identify the file name using the
"content-disposition" header. This is not required, but is as a
convenience for those cases where, for example, the uploaded files
might contain references to each other, e.g., a TeX file and its
.sty auxiliary style description.
multipart/form-data headers may optionally include a Content-Length
header both in the overall reply and in individual components. The
content-length is *not* intended as a replacement for the multipart
boundary as a way of detecting the end of an individual component.
It is *only* supplied as a way forwarning the server of the amount
of data coming.
Person & email address to contact for further information:
Larry Masinter
masinter@parc.xerox.com