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


Registration of new Media Type multipart/form-data


Larry Masinter <[log in to unmask]>


[log in to unmask]


Mon, 10 Apr 95 14:21:09 EDT





text/plain (75 lines)

Media Type name:

Media subtype name:

Required parameters:

Optional parameters:

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

Published specification:

 The original definition of this type is contained in Internet Draft
 draft-ietf-html-fileupload-01.txt, which has been approved by the
 HTML working group to release as an RFC. However, the specification
 of multipart/form-data is contained fully herein:

 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 of which has
 a "Name:" header. 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 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 optionally identify the file name using the
  "content-disposition" header. This is not required, but is as a
  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.

  multipart/form-data headers 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.
  It is *only* supplied as a way forwarning the server of the amount
  of data coming.

Person & email address to contact for further information:

   Larry Masinter
   [log in to unmask]

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



CataList Email List Search Powered by the LISTSERV Email List Manager