From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2388.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2388.txt (limited to 'doc/rfc/rfc2388.txt') diff --git a/doc/rfc/rfc2388.txt b/doc/rfc/rfc2388.txt new file mode 100644 index 0000000..ffb9b6c --- /dev/null +++ b/doc/rfc/rfc2388.txt @@ -0,0 +1,507 @@ + + + + + + +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. + + + + + +Masinter Standards Track [Page 1] + +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 + + 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". + + + + + +Masinter Standards Track [Page 2] + +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 + + + + + +Masinter Standards Track [Page 3] + +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. + +5.3 Remote files with third-party transfer + + In some scenarios, the user operating the form software might want to + specify a URL for remote data rather than a local file. In this case, + is there a way to allow the browser to send to the client a pointer + to the external data rather than the entire contents? This capability + could be implemented, for example, by having the client send to the + server data of type "message/external-body" with "access-type" set + to, say, "uri", and the URL of the remote data in the body of the + message. + +5.4 Non-ASCII field names + + Note that MIME headers are generally required to consist only of 7- + bit data in the US-ASCII character set. Hence field names should be + encoded according to the method in RFC 2047 if they contain + characters outside of that set. + + + + + + + +Masinter Standards Track [Page 4] + +RFC 2388 multipart/form-data August 1998 + + +5.5 Ordered fields and duplicated field names + + The relationship of the ordering of fields within a form and the + ordering of returned values within "multipart/form-data" is not + defined by this specification, nor is the handling of the case where + a form has multiple fields with the same name. While HTML-based forms + may send back results in the order received, and intermediaries + should not reorder the results, there are some systems which might + not define a natural order for form fields. + +5.6 Interoperability with web applications + + Many web applications use the "application/x-url-encoded" method for + returning data from forms. This format is quite compact, e.g.: + + name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send + + however, there is no opportunity to label the enclosed data with + content type, apply a charset, or use other encoding mechanisms. + + Many form-interpreting programs (primarly web browsers) now implement + and generate multipart/form-data, but an existing application might + need to optionally support both the application/x-url-encoded format + as well. + +5.7 Correlating form data with the original form + + This specification provides no specific mechanism by which + multipart/form-data can be associated with the form that caused it to + be transmitted. This separation is intentional; many different forms + might be used for transmitting the same data. In practice, + applications may supply a specific form processing resource (in HTML, + the ACTION attribute in a FORM tag) for each different form. + Alternatively, data about the form might be encoded in a "hidden + field" (a field which is part of the form but which has a fixed value + to be transmitted back to the form-data processor.) + +6. Security Considerations + + The data format described in this document introduces no new security + considerations outside of those introduced by the protocols that use + it and of the component elements. It is important when interpreting + content-disposition to not overwrite files in the recipients address + space inadvertently. + + User applications that request form information from users must be + careful not to cause a user to send information to the requestor or a + third party unwillingly or unwittingly. For example, a form might + + + +Masinter Standards Track [Page 5] + +RFC 2388 multipart/form-data August 1998 + + + request 'spam' information to be sent to an unintended third party, + or private information to be sent to someone that the user might not + actually intend. While this is primarily an issue for the + representation and interpretation of forms themselves, rather than + the data representation of the result of form transmission, the + transportation of private information must be done in a way that does + not expose it to unwanted prying. + + With the introduction of form-data that can reasonably send back the + content of files from user's file space, the possibility that a user + might be sent an automated script that fills out a form and then + sends the user's local file to another address arises. Thus, + additional caution is required when executing automated scripting + where form-data might include user's files. + +7. Author's Address + + Larry Masinter + Xerox Palo Alto Research Center + 3333 Coyote Hill Road + Palo Alto, CA 94304 + + Fax: +1 650 812 4333 + EMail: masinter@parc.xerox.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 6] + +RFC 2388 multipart/form-data August 1998 + + +Appendix A. Media type registration for multipart/form-data + + Media Type name: + multipart + + Media subtype name: + form-data + + Required parameters: + none + + Optional parameters: + none + + Encoding considerations: + No additional considerations other than as for other multipart + types. + + Security Considerations + Applications which receive forms and process them must be careful + not to supply data back to the requesting form processing site that + was not intended to be sent by the recipient. This is a + consideration for any application that generates a multipart/form- + data. + + The multipart/form-data type introduces no new security + considerations for recipients beyond what might occur with any of + the enclosed parts. + + + + + + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 7] + +RFC 2388 multipart/form-data August 1998 + + +References + + [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) + Part Three: Message Header Extensions for Non-ASCII Text", + RFC 2047, November 1996. + + [RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded + Word Extensions: Character Sets, Languages, and + Continuations", RFC 2231, November 1997. + + [RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation + Information in Internet Messages: The Content-Disposition + Header", RFC 1806, June 1995. + + [RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in + HTML", RFC 1867, November 1995. + + [RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating + Presentation Information in Internet Messages: The + Content-Disposition Header Field", RFC 2183, August 1997. + + [RFC 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded + Word Extensions: Character Sets, Languages, and + Continuations", RFC 2184, August 1997. + + [HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 + Specification", World Wide Web Consortium Technical Report + "REC-html40", December, 1997. + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 8] + +RFC 2388 multipart/form-data August 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 9] + -- cgit v1.2.3