LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: (Third? lost count) revised Registration of new Media Type multipart/form-data
From: Larry Masinter <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Tue, 2 May 95 17:01:45 EDT

text/plain (88 lines)

This is revised again as a result of previous comments. The published
specification is now contained within section 7 of the html-fileupload
Media Type name:

Media subtype name:

Required parameters:

Optional parameters:

Encoding considerations:
 No additional considerations other than as for other multipart types.

Published specification:
section 7 of draft-ietf-html-fileupload-02.txt, included below

Security Considerations

  The multipart/form-data type introduces no new security
  considerations beyond what might occur with any of the enclosed

Person & email address to contact for further information:

   Larry Masinter
   [log in to unmask]

Here is section 7 of draft-ietf-html-fileupload-02.txt:

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. The name of the field
 is restricted to be a set of US-ASCII graphic characters; 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.  As with all
 multipart MIME types, each part has an optional Content-Type which
 defaults to text/plain.

 Note that mime headers are generally required to consist only of
 7-bit data in the US-ASCII character set. This specification thus
 requires that the field names used consist of 7-bit ascii US

 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.

  The "content-transfer-encoding" header should be supplied for all
  fields whose values do not conform to the default 7BIT encoding
  (all characters 7-bit US-ASCII data with lines no longer than 1000

  Otherwise, file data and longer field values may be
  transferred using a content-transfer-encoding appropriate to the
  protocol of the ACTION in the form. For HTTP applications,
  content-transfer-encoding of "binary" may be use.  If the ACTION is
  a "mailto:" URL, then the user agent may encode the data
  appropriately to the mail transport mechanism.  [See section 5 of
  RFC 1521 for more details.]

  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.

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager