diff options
Diffstat (limited to 'docs/specs/rfc2388.txt')
| -rw-r--r-- | docs/specs/rfc2388.txt | 507 |
1 files changed, 0 insertions, 507 deletions
diff --git a/docs/specs/rfc2388.txt b/docs/specs/rfc2388.txt deleted file mode 100644 index ffb9b6c9..00000000 --- a/docs/specs/rfc2388.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -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 - <eu>100' where <eu> 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. <http://www.w3.org/TR/REC- - html40/> - - - - - - - - - - - - - - - - - - -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] - |