a content-transfer-encoding of x-compress for file data, and for
   servers to decompress the data before processing, if desired; this
   was left out of the proposal, however.

   Similarly, the 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
   mail.

5.2 Deferred file transmission

   In some situations, it might be advisable to have the server validate
   various elements of the form data (user name, account, etc.)  before
   actually preparing to receive the data.  However, after some
   consideration, it seemed best to require that servers that wish to do
   this should implement this as a series of forms, where some of the
   data elements that were previously validated might be sent back to
   the client as 'hidden' fields, or by arranging the form so that the
   elements that need validation occur first.  This puts the onus of
   maintaining the state of a transaction only on those servers that
   wish to build a complex application, while allowing those cases that
   have simple input needs to be built simply.

   The HTTP protocol may require a content-length for the overall
   transmission. Even if it were not to do so, HTTP clients are
   encouraged to supply content-length for overall file input so that a
   busy server could detect if the proposed file data is too large to be
   processed reasonably and just return an error code and close the
   connection without waiting to process all of the incoming data.  Some
   current implementations of CGI require a content-length in all POST
   transactions.

   If the INPUT tag includes the attribute MAXLENGTH, the user agent
   should consider its value to represent the maximum Content-Length (in




 
RFC 1867             Form-based File Upload in HTML        November 1995


   bytes) which the server will accept for transferred files.  In this
   way, servers can hint to the client how much space they have
   available for a file upload, before that upload takes place.  It is
   important to note, however, that this is only a hint, and the actual
   requirements of the server may change between form creation and file
   submission.

   In any case, a HTTP server may abort a file upload in the middle of
   the transaction if the file being received is too large.

5.3 Other choices for return transmission of binary data

   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 we are not opposed
   to doing so, this would require additional design and standardization
   work to get acceptance of "aggregate".  On the other hand, 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.

5.4 Not overloading :

   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  is important.  In
   addition, the  field *is* already overloaded to contain most
   kinds of data input; rather than creating multiple kinds of 
   tags, it seems most reasonable to enhance .  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  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




 
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