INTERNET-DRAFT E. Nebel File Transmission from WWW Browsers to Servers L. Masinter draft-ietf-html-fileupload-00.txt Xerox Corporation Expires May 18, 1995 November 18, 1994 File Transfer from World-Wide Web Browsers to Servers i. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract Currently, a World-Wide Web server can get information from users with HTML forms. These forms have proven useful in a wide variety of applications in which input from the user is necessary. But this capability is still greatly limited because HTML forms don't provide a way for the user to submit files to the server. Service providers who need to get files from the user have had to implement custom browsers. (Examples of these custom browsers have appeared on the www-talk mailing list.) To avoid the necessity for custom browsers and to make WWW servers complete in their ability to get information from the user, the WWW needs to provide a way for users to send files to servers. Since user information is sent back to the server using HTML forms, it is most logical to extend HTML forms to support file submission. This document proposes an extention to HTML to allow forms to request users supply files as data to be returned when the form has been completely filled out and submitted. It also includes a description of a backward compatibility strategy that allows new servers to interact with old WWW browsers. 2. HTML forms with file submission The current draft HTML specification defines eight possible values for the attribute TYPE of an INPUT element: CHECKBOX, HIDDEN, IMAGE, PASSWORD, RADIO, RESET, SUBMIT, TEXT. In addition, it defines the default ENCTYPE attribute of the FORM element using the POST METHOD to have the default type "application/x-www-form-urlencoded". This proposal makes two changes: 1) add a FILE option for the TYPE attribute of INPUT 2) allow the ENCTYPE of a FORM to be "multipart/www-form-data". These changes might be considered independently, but are both necessary for reasonable file upload. The author of an HTML form who wants to request one or more files from a user would write (for example):
File to process:
The change to the HTML DTD is trivial--just one item added to the entity "InputType", as follows: ... (other elements) ... ... (other elements) ... This is the minimal change requested. Other, larger changes to the InputType entity might also be contemplated but are not part of this proposal. For example, an INPUT element might usefully have an attribute which identifies a set of acceptable media-types, e.g., . 3. Proposed implementation The proposed implementation in WWW browsers is, when a INPUT tag of type FILE is encountered, to show a a display of (previously selected) file names, and a "Browse" button or selection method. Selecting the "Browse" button would cause the browser to enter into a file selection mode appropriate for the platform. Window-based browsers might pops up a file selection window, for example. In such a file selection dialog, the user would have the option of replacing a current selection, adding a new file selection, etc. Browser implementors might choose let the list of file names be manually edited. When the user completes the form, and selects the SUBMIT element, the browser should send the form data and the content of the selected files. The encoding type "application/x-www-form-urlencoded" is inefficient for efficiently sending large quantities of binary data. Thus, a (new) media type, "multipart/www-form-data" is proposed as a way of efficiently sending the values associated with a filled-out form from client to server. The media-type (MIME-type) "multipart/www-form-data" follows the rules of all multipart MIME data streams as outlined in RFC 1521--a boundary is selected that does not occur (with more than infinitessimal probability) in any of the data. Each field of the form is sent, in the order in which it occurs in the form, as a part of the multipart stream. Each part identifies the INPUT name within the original HTML form using a "Name: " attribute. Each part has an optional Content-Type (which defaults to text/plain). File inputs should be identified as either application/binary or the appropriate media type, if known. If multiple files were selected, they should be transferred together using the multipart/mixed format. The "content-transfer-encoding" for each part should be "binary". File inputs may optionally identify the file name using the "Content-Description" header. Browers may optionally include a Content-Length header both in the overall reply and in individual components; the content-length is not intended as a replacement for the multipart boundary as a way of detecting the end of an individual component; rather, it is just as a way forwarning the server of the amount of data coming. On the server end, the ACTION might point to a HTTP URL that implements the forms action via CGI. In such a case, the CGI program would note that the content-type is multipart/www-form-data, parse the various fields (checking for validity, writing the file data to local files for subsequent processing, etc.). 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 , will treat it as 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/www-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 that contained: * 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. This data stream would be marked as application/x-please-send-files. 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/www-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 user.) It would be useful if the status of the transfer of the files involved could be displayed. 5. Other considerations Compression: 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 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. Deferred file transmission: In some situations, it might be advisable to have the server validate various elements of the clients 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. 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. 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, trivial to implement on both the sending client and receiving server, and as efficient as other methods of dealing with multiple combinations of binary data. 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 to work for text browsers or audio-markup. 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. 6. Examples Suppose the server supplies the following HTML: What is your name? What files are you sending?
and the user types "Joe Blow" in the name field, and selects a text file "file1.txt" and also an image file "file2.gif" for the answer to 'What files are you sending?'. The client would send back the following data: Content-type: multipart/www-form-data, boundary=AaB03x --AaB03x Name: field1 Joe Blow --AaB03x Name: pics Content-type: multipart/mixed, boundary=BbC04y --BbC04y Content-Description: file1.txt Content-Type: text/plain ... contents of file1.txt ... --BbC04y Content-Description: file2.gif Content-type: image/gif ...contents of file2.gif... --BbC04y-- --AaB03x-- 7. 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. A. Authors' Addresses Larry Masinter masinter@parc.xerox.com Xerox Palo Alto Research Center Voice: (415) 812-4365 3333 Coyote Hill Road Fax: (415) 812-4333 Palo Alto, CA 94304 Ernesto Nebel nebel@xsoft.sd.xerox.com XSoft, Xerox Corporation Voice: (619) 676-7817 10875 Rancho Bernardo Road, Suite 200 Fax: (619) 676-7865 San Diego, CA 92127-2116