rfc1867.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Various people have wondered about the advisability of overloading
   'INPUT' for this function, rather than merely providing a different
   type of FORM element.  Among other considerations, the migration
   strategy which is allowed when using <INPUT> is important.  In
   addition, the <INPUT> field *is* already overloaded to contain most
   kinds of data input; rather than creating multiple kinds of <INPUT>
   tags, it seems most reasonable to enhance <INPUT>.  The 'type' of
   INPUT is not the content-type of what is returned, but rather the
   'widget-type'; i.e., it identifies the interaction style with the
   user.  The description here is carefully written to allow <INPUT
   TYPE=FILE> to work for text browsers or audio-markup.

5.5 Default content-type of field data

   Many input fields in HTML are to be typed in. There has been some
   ambiguity as to how form data should be transmitted back to servers.
   Making the content-type of <INPUT> fields be text/plain clearly
   disambiguates that the client should properly encode the data before
   sending it back to the server with CRLFs.

5.6 Allow form ACTION to be "mailto:"

   Independent of this proposal, it would be very useful for HTML
   interpreting user agents to allow a ACTION in a form to be a



Nebel & Masinter              Experimental                      [Page 7]

RFC 1867             Form-based File Upload in HTML        November 1995


   "mailto:" URL. This seems like a good idea, with or without this
   proposal. Similarly, the ACTION for a HTML form which is received via
   mail should probably default to the "reply-to:" of the message.
   These two proposals would allow HTML forms to be served via HTTP
   servers but sent back via mail, or, alternatively, allow HTML forms
   to be sent by mail, filled out by HTML-aware mail recipients, and the
   results mailed back.

5.7 Remote files with third-party transfer

   In some scenarios, the user operating the client 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.8 File transfer with ENCTYPE=x-www-form-urlencoded

   If a form contains <INPUT TYPE=file> elements but does not contain an
   ENCTYPE in the enclosing <FORM>, the behavior is not specified.  It
   is probably inappropriate to attempt to URN-encode large quantities
   of data to servers that don't expect it.

5.9 CRLF used as line separator

   As with all MIME transmissions, CRLF is used as the separator for
   lines in a POST of the data in multipart/form-data.

5.10 Relationship to multipart/related

   The MIMESGML group is proposing a new type called multipart/related.
   While it contains similar features to multipart/form-data, the use
   and application of form-data is different enough that form-data is
   being described separately.

   It might be possible at some point to encode the result of HTML forms
   (including files) in a multipart/related body part; this is not
   incompatible with this proposal.

5.11 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 prescriptions of RFC 1522 if they contain
   characters outside of that set. In HTML 2.0, the default character



Nebel & Masinter              Experimental                      [Page 8]

RFC 1867             Form-based File Upload in HTML        November 1995


   set is ISO-8859-1, but non-ASCII characters in field names should be
   encoded.

6. Examples

   Suppose the server supplies the following HTML:

     <FORM ACTION="http://server.dom/cgi/handle"
           ENCTYPE="multipart/form-data"
           METHOD=POST>
     What is your name? <INPUT TYPE=TEXT NAME=submitter>
     What files are you sending? <INPUT TYPE=FILE NAME=pics>
     </FORM>

   and the user types "Joe Blow" in the name field, and selects a text
   file "file1.txt" for the answer to 'What files are you sending?'

   The client might send back the following data:

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"; filename="file1.txt"
        Content-Type: text/plain

         ... contents of file1.txt ...
        --AaB03x--

   If the user also indicated an image file "file2.gif" for the answer
   to 'What files are you sending?', the client might client might send
   back the following data:

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"
        Content-type: multipart/mixed, boundary=BbC04y

        --BbC04y
        Content-disposition: attachment; filename="file1.txt"



Nebel & Masinter              Experimental                      [Page 9]

RFC 1867             Form-based File Upload in HTML        November 1995


        Content-Type: text/plain

        ... contents of file1.txt ...
        --BbC04y
        Content-disposition: attachment; filename="file2.gif"
        Content-type: image/gif
        Content-Transfer-Encoding: binary

          ...contents of file2.gif...
        --BbC04y--
        --AaB03x--

7. Registration of multipart/form-data

   The media-type multipart/form-data follows the rules of all multipart
   MIME data streams as outlined in RFC 1521. It is intended for use in
   returning the data that comes about from filling out a form. In a
   form (in HTML, although other applications may also use 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 where the value is "form-
   data" and a name attribute specifies the field name within the form,
   e.g., 'content-disposition: form-data; name="xxxxx"', where xxxxx is
   the field name corresponding to that field. Field names originally in
   non-ASCII character sets may be encoded using the method outlined in
   RFC 1522.

   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
   application/octet-stream or the appropriate media type, if known.  If
   multiple files are to be returned as the result of a single form
   entry, they can be returned as multipart/mixed 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.

   File inputs may also identify the file name. The file name may be
   described using the 'filename' parameter of the "content-disposition"
   header. This is not required, but is strongly recommended in any case
   where the original filename is known. This is useful or necessary in
   many applications.




Nebel & Masinter              Experimental                     [Page 10]

RFC 1867             Form-based File Upload in HTML        November 1995


8. Security Considerations

   It is important that a user agent not send any file that the user has
   not explicitly asked to be sent. Thus, HTML interpreting agents are
   expected to confirm any default file names that might be suggested
   with <INPUT TYPE=file VALUE="yyyy">.  Never have any hidden fields be
   able to specify any file.

   This proposal does not contain a mechanism for encryption of the
   data; this should be handled by whatever other mechanisms are in
   place for secure transmission of data, whether via secure HTTP, or by
   security provided by MOSS (described in RFC 1848).

   Once the file is uploaded, it is up to the receiver to process and
   store the file appropriately.

9.  Conclusion

   The suggested implementation gives the client a lot of flexibility in
   the number and types of files it can send to the server, it gives the
   server control of the decision to accept the files, and it gives
   servers a chance to interact with browsers which do not support INPUT
   TYPE "file".

   The change to the HTML DTD is very simple, but very powerful.  It
   enables a much greater variety of services to be implemented via the
   World-Wide Web than is currently possible due to the lack of a file
   submission facility.  This would be an extremely valuable addition to
   the capabilities of the World-Wide Web.






















Nebel & Masinter              Experimental                     [Page 11]

RFC 1867             Form-based File Upload in HTML        November 1995


Authors' Addresses

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone:  [phone]
   Fax:    [phone]
   EMail:   [e-mail]


   Ernesto Nebel
   XSoft, Xerox Corporation
   10875 Rancho Bernardo Road, Suite 200
   San Diego, CA 92127-2116

   Phone:  [phone]
   Fax:    [phone]
   EMail:   [e-mail]































Nebel & Masinter              Experimental                     [Page 12]

RFC 1867             Form-based File Upload in HTML        November 1995


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.

Published specification:
 RFC 1867

Security Considerations

  The multipart/form-data type introduces no new security
  considerations beyond what might occur with any of the enclosed
  parts.

References

[RFC 1521] MIME (Multipurpose Internet Mail Extensions) Part One:
           Mechanisms for Specifying and Describing the Format of
           Internet Message Bodies.  N. Borenstein & N. Freed.
           September 1993.

[RFC 1522] MIME (Multipurpose Internet Mail Extensions) Part Two:
           Message Header Extensions for Non-ASCII Text. K. Moore.
           September 1993.

[RFC 1806] Communicating Presentation Information in Internet
           Messages: The Content-Disposition Header. R. Troost & S.
           Dorner, June 1995.











Nebel & Masinter              Experimental                     [Page 13]