"Fossies" - the Fresh Open Source Software Archive

Member "libgcgi.a-0.9.5/doc/rfc2388.txt" (22 Jun 2002, 16531 Bytes) of package /linux/www/old/gcgi-0.9.5.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 
    2 
    3 
    4 
    5 
    6 
    7 Network Working Group                                         L. Masinter
    8 Request for Comments: 2388                              Xerox Corporation
    9 Category: Standards Track                                     August 1998
   10 
   11 
   12            Returning Values from Forms:  multipart/form-data
   13 
   14 Status of this Memo
   15 
   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.
   21 
   22 Copyright Notice
   23 
   24    Copyright (C) The Internet Society (1998).  All Rights Reserved.
   25 
   26 1. Abstract
   27 
   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.
   32 
   33 2. Introduction
   34 
   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.
   40 
   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
   46    servers.
   47 
   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.
   53 
   54 
   55 
   56 
   57 
   58 Masinter                    Standards Track                     [Page 1]
   59 
   60 RFC 2388                  multipart/form-data                August 1998
   61 
   62 
   63 3. Definition of multipart/form-data
   64 
   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.
   69 
   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:
   76 
   77         Content-Disposition: form-data; name="user"
   78 
   79    with the value corresponding to the entry of the "user" field.
   80 
   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.
   84 
   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".
   92 
   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
   95    encoding.
   96 
   97 4. Use of multipart/form-data
   98 
   99 4.1 Boundary
  100 
  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".
  109 
  110 
  111 
  112 
  113 
  114 Masinter                    Standards Track                     [Page 2]
  115 
  116 RFC 2388                  multipart/form-data                August 1998
  117 
  118 
  119 4.2 Sets of files
  120 
  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.
  124 
  125 4.3 Encoding
  126 
  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.]
  132 
  133 4.4 Other attributes
  134 
  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
  137    2184].
  138 
  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.
  146 
  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.
  150 
  151 4.5 Charset of text in form data
  152 
  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.
  156 
  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
  159    as:
  160 
  161     --AaB03x
  162     content-disposition: form-data; name="field1"
  163     content-type: text/plain;charset=windows-1250
  164     content-transfer-encoding: quoted-printable
  165 
  166 
  167 
  168 
  169 
  170 Masinter                    Standards Track                     [Page 3]
  171 
  172 RFC 2388                  multipart/form-data                August 1998
  173 
  174 
  175     Joe owes =80100.
  176     --AaB03x
  177 
  178 5. Operability considerations
  179 
  180 5.1 Compression, encryption
  181 
  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.
  185 
  186 5.2 Other data encodings rather than multipart
  187 
  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
  195    binary data.
  196 
  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.
  201 
  202 5.3 Remote files with third-party transfer
  203 
  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
  211    message.
  212 
  213 5.4 Non-ASCII field names
  214 
  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.
  219 
  220 
  221 
  222 
  223 
  224 
  225 
  226 Masinter                    Standards Track                     [Page 4]
  227 
  228 RFC 2388                  multipart/form-data                August 1998
  229 
  230 
  231 5.5 Ordered fields and duplicated field names
  232 
  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.
  240 
  241 5.6 Interoperability with web applications
  242 
  243    Many web applications use the "application/x-url-encoded" method for
  244    returning data from forms. This format is quite compact, e.g.:
  245 
  246    name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
  247 
  248    however, there is no opportunity to label the enclosed data with
  249    content type, apply a charset, or use other encoding mechanisms.
  250 
  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
  254    as well.
  255 
  256 5.7 Correlating form data with the original form
  257 
  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.)
  267 
  268 6. Security Considerations
  269 
  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
  274    space inadvertently.
  275 
  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
  279 
  280 
  281 
  282 Masinter                    Standards Track                     [Page 5]
  283 
  284 RFC 2388                  multipart/form-data                August 1998
  285 
  286 
  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.
  294 
  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.
  301 
  302 7. Author's Address
  303 
  304    Larry Masinter
  305    Xerox Palo Alto Research Center
  306    3333 Coyote Hill Road
  307    Palo Alto, CA 94304
  308 
  309    Fax:    +1 650 812 4333
  310    EMail:   masinter@parc.xerox.com
  311 
  312 
  313 
  314 
  315 
  316 
  317 
  318 
  319 
  320 
  321 
  322 
  323 
  324 
  325 
  326 
  327 
  328 
  329 
  330 
  331 
  332 
  333 
  334 
  335 
  336 
  337 
  338 Masinter                    Standards Track                     [Page 6]
  339 
  340 RFC 2388                  multipart/form-data                August 1998
  341 
  342 
  343 Appendix A. Media type registration for multipart/form-data
  344 
  345    Media Type name:
  346      multipart
  347 
  348    Media subtype name:
  349      form-data
  350 
  351    Required parameters:
  352      none
  353 
  354    Optional parameters:
  355      none
  356 
  357    Encoding considerations:
  358      No additional considerations other than as for other multipart
  359      types.
  360 
  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-
  366      data.
  367 
  368      The multipart/form-data type introduces no new security
  369      considerations for recipients beyond what might occur with any of
  370      the enclosed parts.
  371 
  372 
  373 
  374 
  375 
  376 
  377 
  378 
  379 
  380 
  381 
  382 
  383 
  384 
  385 
  386 
  387 
  388 
  389 
  390 
  391 
  392 
  393 
  394 Masinter                    Standards Track                     [Page 7]
  395 
  396 RFC 2388                  multipart/form-data                August 1998
  397 
  398 
  399 References
  400 
  401    [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
  402               Extensions (MIME) Part Two: Media Types", RFC 2046,
  403               November 1996.
  404 
  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.
  408 
  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.
  412 
  413    [RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation
  414               Information in Internet Messages: The Content-Disposition
  415               Header", RFC 1806, June 1995.
  416 
  417    [RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in
  418               HTML", RFC 1867, November 1995.
  419 
  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.
  423 
  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.
  427 
  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-
  431               html40/>
  432 
  433 
  434 
  435 
  436 
  437 
  438 
  439 
  440 
  441 
  442 
  443 
  444 
  445 
  446 
  447 
  448 
  449 
  450 Masinter                    Standards Track                     [Page 8]
  451 
  452 RFC 2388                  multipart/form-data                August 1998
  453 
  454 
  455 Full Copyright Statement
  456 
  457    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  458 
  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
  471    English.
  472 
  473    The limited permissions granted above are perpetual and will not be
  474    revoked by the Internet Society or its successors or assigns.
  475 
  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.
  482 
  483 
  484 
  485 
  486 
  487 
  488 
  489 
  490 
  491 
  492 
  493 
  494 
  495 
  496 
  497 
  498 
  499 
  500 
  501 
  502 
  503 
  504 
  505 
  506 Masinter                    Standards Track                     [Page 9]
  507