Network Working Group L. Masinter
Request for Comments: 2388 Xerox Corporation
Category: Standards Track August 1998
Returning Values from Forms: multipart/form-data
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Abstract
This specification defines an Internet Media Type, multipart/form-
data, 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.
2. Introduction
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 [RFC1867] and subsequently
incorporated into [HTML40], where forms are expressed in HTML, and in
which the form values are sent via HTTP or electronic mail. This
representation is widely implemented in numerous web browsers and web
servers.
However, multipart/form-data can be used for forms that are presented
using representations other than HTML (spreadsheets, Portable
Document Format, etc), and for transport using other means than
electronic mail or HTTP. This document defines the representation of
form values independently of the application for which it is used.
RFC 2388 multipart/form-data August 1998
3. Definition of multipart/form-data
The media-type multipart/form-data follows the rules of all multipart
MIME data streams as outlined in [RFC 2046]. In forms, there are a
series of fields to be supplied by the user who fills out the form.
Each field has a name. 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 [RFC 2183] where the
disposition type is "form-data", and where the disposition contains
an (additional) parameter of "name", where the value of that
parameter is the original field name in the form. For example, a part
might contain a header:
Content-Disposition: form-data; name="user"
with the value corresponding to the entry of the "user" field.
Field names originally in non-ASCII character sets may be encoded
within the value of the "name" parameter using the standard method
described in RFC 2047.
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 the appropriate media type, if known, or
"application/octet-stream". If multiple files are to be returned as
the result of a single form entry, they should be represented as a
"multipart/mixed" part embedded within the "multipart/form-data".
Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.
4. Use of multipart/form-data
4.1 Boundary
=1= |