7 Network Working Group L. Masinter
8 Request for Comments: 2388 Xerox Corporation
9 Category: Standards Track August 1998
12 Returning Values from Forms: multipart/form-data
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (1998). All Rights Reserved.
28 This specification defines an Internet Media Type, multipart/form-
29 data, which can be used by a wide variety of applications and
30 transported by a wide variety of protocols as a way of returning a
31 set of values as the result of a user filling out a form.
35 In many applications, it is possible for a user to be presented with
36 a form. The user will fill out the form, including information that
37 is typed, generated by user input, or included from files that the
38 user has selected. When the form is filled out, the data from the
39 form is sent from the user to the receiving application.
41 The definition of MultiPart/Form-Data is derived from one of those
42 applications, originally set out in [RFC1867] and subsequently
43 incorporated into [HTML40], where forms are expressed in HTML, and in
44 which the form values are sent via HTTP or electronic mail. This
45 representation is widely implemented in numerous web browsers and web
48 However, multipart/form-data can be used for forms that are presented
49 using representations other than HTML (spreadsheets, Portable
50 Document Format, etc), and for transport using other means than
51 electronic mail or HTTP. This document defines the representation of
52 form values independently of the application for which it is used.
58 Masinter Standards Track [Page 1]
60 RFC 2388 multipart/form-data August 1998
63 3. Definition of multipart/form-data
65 The media-type multipart/form-data follows the rules of all multipart
66 MIME data streams as outlined in [RFC 2046]. In forms, there are a
67 series of fields to be supplied by the user who fills out the form.
68 Each field has a name. Within a given form, the names are unique.
70 "multipart/form-data" contains a series of parts. Each part is
71 expected to contain a content-disposition header [RFC 2183] where the
72 disposition type is "form-data", and where the disposition contains
73 an (additional) parameter of "name", where the value of that
74 parameter is the original field name in the form. For example, a part
75 might contain a header:
77 Content-Disposition: form-data; name="user"
79 with the value corresponding to the entry of the "user" field.
81 Field names originally in non-ASCII character sets may be encoded
82 within the value of the "name" parameter using the standard method
83 described in RFC 2047.
85 As with all multipart MIME types, each part has an optional
86 "Content-Type", which defaults to text/plain. If the contents of a
87 file are returned via filling out a form, then the file input is
88 identified as the appropriate media type, if known, or
89 "application/octet-stream". If multiple files are to be returned as
90 the result of a single form entry, they should be represented as a
91 "multipart/mixed" part embedded within the "multipart/form-data".
93 Each part may be encoded and the "content-transfer-encoding" header
94 supplied if the value of that part does not conform to the default
97 4. Use of multipart/form-data
101 As with other multipart types, a boundary is selected that does not
102 occur in any of the data. Each field of the form is sent, in the
103 order defined by the sending appliction and form, as a part of the
104 multipart stream. Each part identifies the INPUT name within the
105 original form. Each part should be labelled with an appropriate
106 content-type if the media type is known (e.g., inferred from the file
107 extension or operating system typing information) or as
108 "application/octet-stream".
114 Masinter Standards Track [Page 2]
116 RFC 2388 multipart/form-data August 1998
121 If the value of a form field is a set of files rather than a single
122 file, that value can be transferred together using the
123 "multipart/mixed" format.
127 While the HTTP protocol can transport arbitrary binary data, the
128 default for mail transport is the 7BIT encoding. The value supplied
129 for a part may need to be encoded and the "content-transfer-encoding"
130 header supplied if the value does not conform to the default
131 encoding. [See section 5 of RFC 2046 for more details.]
135 Forms may request file inputs from the user; the form software may
136 include the file name and other file attributes, as specified in [RFC
139 The original local file name may be supplied as well, either as a
140 "filename" parameter either of the "content-disposition: form-data"
141 header or, in the case of multiple files, in a "content-disposition:
142 file" header of the subpart. The sending application MAY supply a
143 file name; if the file name of the sender's operating system is not
144 in US-ASCII, the file name might be approximated, or encoded using
145 the method of RFC 2231.
147 This is a convenience for those cases where the files supplied by the
148 form might contain references to each other, e.g., a TeX file and its
149 .sty auxiliary style description.
151 4.5 Charset of text in form data
153 Each part of a multipart/form-data is supposed to have a content-
154 type. In the case where a field element is text, the charset
155 parameter for the text indicates the character encoding used.
157 For example, a form with a text field in which a user typed 'Joe owes
158 <eu>100' where <eu> is the Euro symbol might have form data returned
162 content-disposition: form-data; name="field1"
163 content-type: text/plain;charset=windows-1250
164 content-transfer-encoding: quoted-printable
170 Masinter Standards Track [Page 3]
172 RFC 2388 multipart/form-data August 1998
178 5. Operability considerations
180 5.1 Compression, encryption
182 Some of the data in forms may be compressed or encrypted, using other
183 MIME mechanisms. This is a function of the application that is
184 generating the form-data.
186 5.2 Other data encodings rather than multipart
188 Various people have suggested using new mime top-level type
189 "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of
190 "packet" to express indeterminate-length binary data, rather than
191 relying on the multipart-style boundaries. While this would be
192 useful, the "multipart" mechanisms are well established, simple to
193 implement on both the sending client and receiving server, and as
194 efficient as other methods of dealing with multiple combinations of
197 The multipart/form-data encoding has a high overhead and performance
198 impact if there are many fields with short values. However, in
199 practice, for the forms in use, for example, in HTML, the average
200 overhead is not significant.
202 5.3 Remote files with third-party transfer
204 In some scenarios, the user operating the form software might want to
205 specify a URL for remote data rather than a local file. In this case,
206 is there a way to allow the browser to send to the client a pointer
207 to the external data rather than the entire contents? This capability
208 could be implemented, for example, by having the client send to the
209 server data of type "message/external-body" with "access-type" set
210 to, say, "uri", and the URL of the remote data in the body of the
213 5.4 Non-ASCII field names
215 Note that MIME headers are generally required to consist only of 7-
216 bit data in the US-ASCII character set. Hence field names should be
217 encoded according to the method in RFC 2047 if they contain
218 characters outside of that set.
226 Masinter Standards Track [Page 4]
228 RFC 2388 multipart/form-data August 1998
231 5.5 Ordered fields and duplicated field names
233 The relationship of the ordering of fields within a form and the
234 ordering of returned values within "multipart/form-data" is not
235 defined by this specification, nor is the handling of the case where
236 a form has multiple fields with the same name. While HTML-based forms
237 may send back results in the order received, and intermediaries
238 should not reorder the results, there are some systems which might
239 not define a natural order for form fields.
241 5.6 Interoperability with web applications
243 Many web applications use the "application/x-url-encoded" method for
244 returning data from forms. This format is quite compact, e.g.:
246 name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
248 however, there is no opportunity to label the enclosed data with
249 content type, apply a charset, or use other encoding mechanisms.
251 Many form-interpreting programs (primarly web browsers) now implement
252 and generate multipart/form-data, but an existing application might
253 need to optionally support both the application/x-url-encoded format
256 5.7 Correlating form data with the original form
258 This specification provides no specific mechanism by which
259 multipart/form-data can be associated with the form that caused it to
260 be transmitted. This separation is intentional; many different forms
261 might be used for transmitting the same data. In practice,
262 applications may supply a specific form processing resource (in HTML,
263 the ACTION attribute in a FORM tag) for each different form.
264 Alternatively, data about the form might be encoded in a "hidden
265 field" (a field which is part of the form but which has a fixed value
266 to be transmitted back to the form-data processor.)
268 6. Security Considerations
270 The data format described in this document introduces no new security
271 considerations outside of those introduced by the protocols that use
272 it and of the component elements. It is important when interpreting
273 content-disposition to not overwrite files in the recipients address
276 User applications that request form information from users must be
277 careful not to cause a user to send information to the requestor or a
278 third party unwillingly or unwittingly. For example, a form might
282 Masinter Standards Track [Page 5]
284 RFC 2388 multipart/form-data August 1998
287 request 'spam' information to be sent to an unintended third party,
288 or private information to be sent to someone that the user might not
289 actually intend. While this is primarily an issue for the
290 representation and interpretation of forms themselves, rather than
291 the data representation of the result of form transmission, the
292 transportation of private information must be done in a way that does
293 not expose it to unwanted prying.
295 With the introduction of form-data that can reasonably send back the
296 content of files from user's file space, the possibility that a user
297 might be sent an automated script that fills out a form and then
298 sends the user's local file to another address arises. Thus,
299 additional caution is required when executing automated scripting
300 where form-data might include user's files.
305 Xerox Palo Alto Research Center
306 3333 Coyote Hill Road
310 EMail: masinter@parc.xerox.com
338 Masinter Standards Track [Page 6]
340 RFC 2388 multipart/form-data August 1998
343 Appendix A. Media type registration for multipart/form-data
357 Encoding considerations:
358 No additional considerations other than as for other multipart
361 Security Considerations
362 Applications which receive forms and process them must be careful
363 not to supply data back to the requesting form processing site that
364 was not intended to be sent by the recipient. This is a
365 consideration for any application that generates a multipart/form-
368 The multipart/form-data type introduces no new security
369 considerations for recipients beyond what might occur with any of
394 Masinter Standards Track [Page 7]
396 RFC 2388 multipart/form-data August 1998
401 [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
402 Extensions (MIME) Part Two: Media Types", RFC 2046,
405 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
406 Part Three: Message Header Extensions for Non-ASCII Text",
407 RFC 2047, November 1996.
409 [RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
410 Word Extensions: Character Sets, Languages, and
411 Continuations", RFC 2231, November 1997.
413 [RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation
414 Information in Internet Messages: The Content-Disposition
415 Header", RFC 1806, June 1995.
417 [RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in
418 HTML", RFC 1867, November 1995.
420 [RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating
421 Presentation Information in Internet Messages: The
422 Content-Disposition Header Field", RFC 2183, August 1997.
424 [RFC 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
425 Word Extensions: Character Sets, Languages, and
426 Continuations", RFC 2184, August 1997.
428 [HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
429 Specification", World Wide Web Consortium Technical Report
430 "REC-html40", December, 1997. <http://www.w3.org/TR/REC-
450 Masinter Standards Track [Page 8]
452 RFC 2388 multipart/form-data August 1998
455 Full Copyright Statement
457 Copyright (C) The Internet Society (1998). All Rights Reserved.
459 This document and translations of it may be copied and furnished to
460 others, and derivative works that comment on or otherwise explain it
461 or assist in its implementation may be prepared, copied, published
462 and distributed, in whole or in part, without restriction of any
463 kind, provided that the above copyright notice and this paragraph are
464 included on all such copies and derivative works. However, this
465 document itself may not be modified in any way, such as by removing
466 the copyright notice or references to the Internet Society or other
467 Internet organizations, except as needed for the purpose of
468 developing Internet standards in which case the procedures for
469 copyrights defined in the Internet Standards process must be
470 followed, or as required to translate it into languages other than
473 The limited permissions granted above are perpetual and will not be
474 revoked by the Internet Society or its successors or assigns.
476 This document and the information contained herein is provided on an
477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
506 Masinter Standards Track [Page 9]