rfc2388.txt

C/C++语言的CGI接口库

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:    [phone]
   EMail:   [e-mail]



























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]