3.4 Interpretation of other attributes

   The VALUE attribute might be used with <INPUT TYPE=file> tags for a
   default file name. This use is probably platform dependent.  It might
   be useful, however, in sequences of more than one transaction, e.g.,
   to avoid having the user prompted for the same file name over and
   over again.

   The SIZE attribute might be specified using SIZE=width,height, where
   width is some default for file name width, while height is the
   expected size showing the list of selected files.  For example, this
   would be useful for forms designers who expect to get several files
   and who would like to show a multiline file input field in the
   browser (with a "browse" button beside it, hopefully).  It would be
   useful to show a one line text field when no height is specified
   (when the forms designer expects one file, only) and to show a
   multiline text area with scrollbars when the height is greater than 1
   (when the forms designer expects multiple files).







 
RFC 1867             Form-based File Upload in HTML        November 1995


4.  Backward compatibility issues

   While not necessary for successful adoption of an enhancement to the
   current WWW form mechanism, it is useful to also plan for a migration
   strategy: users with older browsers can still participate in file
   upload dialogs, using a helper application. Most current web browers,
   when given <INPUT TYPE=FILE>, will treat it as <INPUT TYPE=TEXT> and
   give the user a text box. The user can type in a file name into this
   text box. In addition, current browsers seem to ignore the ENCTYPE
   parameter in the  element, and always transmit the data as
   application/x-www-form-urlencoded.

   Thus, the server CGI might be written in a way that would note that
   the form data returned had content-type application/x-www-form-
   urlencoded instead of multipart/form-data, and know that the user was
   using a browser that didn't implement file upload.

   In this case, rather than replying with a "text/html" response, the
   CGI on the server could instead send back a data stream that a helper
   application might process instead; this would be a data stream of
   type "application/x-please-send-files", which contains:

   * The (fully qualified) URL to which the actual form data should
     be posted (terminated with CRLF)
   * The list of field names that were supposed to be file contents
     (space separated, terminated with CRLF)
   * The entire original application/x-www-form-urlencoded form data
     as originally sent from client to server.

   In this case, the browser needs to be configured to process
   application/x-please-send-files to launch a helper application.

   The helper would read the form data, note which fields contained
   'local file names' that needed to be replaced with their data
   content, might itself prompt the user for changing or adding to the
   list of files available, and then repackage the data & file contents
   in multipart/form-data for retransmission back to the server.

   The helper would generate the kind of data that a 'new' browser
   should actually have sent in the first place, with the intention that
   the URL to which it is sent corresponds to the original ACTION URL.
   The point of this is that the server can use the *same* CGI to
   implement the mechanism for dealing with both old and new browsers.

   The helper need not display the form data, but *should* ensure that
   the user actually be prompted about the suitability of sending the
   files requested (this is to avoid a security problem with malicious
   servers that ask for files that weren't actually promised by the




 
RFC 1867             Form-based File Upload in HTML        November 1995


   user.) It would be useful if the status of the transfer of the files
   involved could be displayed.

5.  Other considerations

5.1 Compression, encryption

   This scheme doesn't address the possible compression of files.  After
   some consideration, it seemed that the optimization issues of file
   compression were too complex to try to automatically have browsers
   decide that files should be compressed.  Many link-layer transport
   mechanisms (e.g., high-speed modems) perform data compression over
   the link, and optimizing for compression at this layer might not be
   appropriate. It might be possible for browsers to optionally produce