Imported Upstream version 2.46.0upstream/2.46.0

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]
-