Rfc1867 (request annotation) Specification

</P> <p> Network Working Group E. nebel <br/> request for comments: 1867 L. masinter <br/> category: experimental Xerox Corporation <br/> November 1995 </P> <p> form-based file upload in HTML </P> <p> Status of this memo </P> <p> this memo defines an experimental protocol for the Internet <br/> community. this memo does not specify an internet standard of any <br/> kind. discussion and suggestions for improvement are requested. <br/> distribution of this memo is unlimited. </P> <p> 1. abstract </P> <p> currently, HTML forms allow the producer of the form to request <br/> information from the user reading the form. these forms have proven <br/> useful in a wide variety of applications in which input from the user <br/> is necessary. however, this capability is limited because HTML forms <br/> don't provide a way to ask the user to submit files of data. service <br/> providers who need to get files from the user have had to implement <br/> Custom User applications. (Examples of these custom browsers have <br/> appeared on the WWW-talk mailing list .) since file-upload is a <br/> feature that will benefit your applications, this proposes an <br/> extension to HTML to allow information providers to express file <br/> upload requests uniformly, and a MIME compatible representation for <br/> File Upload responses. this also nodes A description of a <br/> backward compatibility strategy that allows new servers to interact <br/> with the current HTML user agents. </P> <p> the proposal is independent of which version of HTML it becomes a <br/> part. </P> <p> 2. HTML forms with file submission </P> <p> the current HTML Specification defines eight possible values for the <br/> attribute type of an input element: checkbox, hidden, image, <br/> password, radio, reset, submit, text. </P> <p> In addition, it defines the default enctype attribute of the form <br/> element using the POST method to have the default value <br/> "application/X-WWW-form-urlencoded ". </P> <p> Nebel & amp; masinter experimental [page 1] </P> <p> RFC 1867 form-based file upload in HTML November 1995 </P> <p> this proposal makes two changes to HTML: </P> <p> 1) Add a file option for the Type attribute of input. <br/> 2) Allow an accept attribute for input tag, which is a list of <br/> media types or type patterns allowed for the input. </P> <p> In addition, it defines a new mime media type, multipart/form-data, <br/> and specifies the behavior of HTML user agents when interpreting a <br/> form with enctype = "multipart/form-Data" and/or <input type = "file"> <br/> tags. </P> <p> these changes might be considered independently, but are all <br/> necessary for reasonable file upload. </P> <p> the author of an HTML form who wants to request one or more files <br/> from a user wocould write (for example ): </P> <p>

The change to the html dtd is to add one item to the entity
"Inputtype". In addition, it is proposed that the input tag have
Accept attribute, which is a list of comma-separated media types.

... (Other elements )...

Nebel & masinter experimental [page 2]

RFC 1867 form-based file upload in HTML November 1995

... (Other elements )...

3. Suggested implementation

While user agents that interpret HTML have wide leeway to choose
Most appropriate mechanic for their context, this section suggests
How one class of user agent, WWW browsers, might implement File
Upload.

3.1 display of file widget

When a input tag of type file is encountered, the browser might show
A display of (previusly selected) file names, and a "Browse" button
Or selection method. Selecting the "Browse" button wocould cause
Browser to enter into a file selection mode appropriate for
Platform. window-based browsers might pop up a file selection window,
For example. In such a file selection diple, the user wocould have
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.

If an accept attribute is present, the browser might constrain
File patterns prompted for to match those with the corresponding
Appropriate file extensions for the platform.

3.2 Action on submit

When the user completes the form, and selects the submit element,
Browser shocould send the form data and the content of the selected
Files. The encoding type application/X-WWW-form-urlencoded is
Inefficient for sending large quantities of binary data or text
Containing Non-ASCII characters. Thus, a new media type,
Multipart/form-data, is proposed as a way of efficiently sending
Values associated with a filled-out form from client to server.

3.3 Use of multipart/form-Data

The definition of multipart/form-data is wrongly ded in Section 7.
Boundary is selected that does not occur in any of the data. (This
Selection is sometimes done probabilisticly.) each field of the form
Is sent, in the order in which it occurs in the form, as a part
The multipart stream. Each Part identifies the input name within
Original HTML form. Each part shoshould be labeled with an appropriate
Content-Type if the media type is known (e.g., inferred from the file
Extension or operating system typing information) or
Application/octet-stream.

Nebel & masinter experimental [Page 3]

RFC 1867 form-based file upload in HTML November 1995

If multiple files are selected, they shoshould be transferred together
Using the multipart/mixed format.

While the HTTP protocol can transport arbitrary binary data,
Default for mail transport (e.g., if the action is a "mailto:" url)
Is the 7bit encoding. The value supplied for a part may need to be
Encoded and the "content-transfer-encoding" header supplied if
Value does not conform to the default encoding. [See section 5
RFC 1521 For more details.]

The original local file name may be supplied as well, either as
'Filename' parameter either of the 'content-Disposition: Form-data'
Header or in the case of multiple files in a 'content-Disposition:
File 'header of the Subpart. The client application shocould make best
Effort to supply the file name; if the file name of the client's
Operating system is not in US-ASCII, the file name might be
Approximated or encoded using the method of RFC 1522. This is
Convenience for those cases where, for example, the uploaded files
Might contain references to each other, e.g., a Tex file and Its. sty
Auxiliary style description.

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
Wocould note that the Content-Type is multipart/form-data, parse
Various fields (checking for validity, writing the file data to local
Files for subsequent processing, etc .).

3.4 interpretation of other attributes

The Value Attribute might be usedTags for
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
Expected size showing the list of selected files. For example, this
Wocould be useful for forms designers who has CT to get several files
And who wowould like to show a multiline file input field in
Browser (with a "Browse" button beside it, hopefully). It wocould 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
Multiline text area with scrollbars when the height is greater than 1
(When the forms designer expects multiple files ).

Nebel & masinter experimental [page 4]

RFC 1867 form-based file upload in HTML November 1995

4. Backward compatibility issues

While not necessary for successful adoption of an enhancement to
Current WWW form mechanic, it is useful to also plan for a migration
Strategy: users with older browsers can still particle in file
Upload dialogs, using a helper application. Most current Web browers,
When given, Will treat itAnd
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

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 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
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
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
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
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 stronugly recommended in any case
Where the original filename is known. This is useful or necessary in
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. Never have any hidden fields be
Able to specify any file.

This proposal does not contain a mechanic for encryption of
Data; this shoshould be handled by whatever other mechanic are in
Place for secure transmission of data, whether via secure HTTP, or
Security provided by Moss (described in RFC 1848 ).

Once the file is uploaded, it is up to the processing er 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
Server Control of the describe 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
World-Wide Web than is currently possible due to the lack of a file
Submission facility. This wocould be an extremely valuable addition
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: (415) 812-4365
Fax: (415) 812-4333
Email: masinter@parc.xerox.com

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

Phone: (619) 676-7817
Fax: (619) 676-7865
Email: nebel@xsoft.sd.xerox.com

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:
Machisms for specifying and describing the format
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]