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




 
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.





 
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.