|[ Up (Contents) ]||Page Last Updated: 13 April 1998|
MIME, for Multipurpose Internet Mail Extensions, is the part of the Internet mail system that allows for multimedia electronic mail. MIME is also used on the Web to define the type of a piece of data (e.g., text/html), and to send complex multipart messages (messages with multiple parts) via HTTP. Thus, every Web expert should understand the basics of the MIME mechanisms. The aim of this appendix is to provide this basic knowledge.
The original Internet mail message protocol, defined in RFC 822, was designed with text mail messages in mind. A mail message was defined as a block of plain text preceded by specially defined headers specifying routing or other information about the message (e.g., where the message was from, who it was to, who copies were sent to, etc.). This specification said little about the format of the message content. At the time (which was not that long ago!), electronic mail messages were plain text files, so that concerns about the format of content were unwarranted. My, how things have changed!
Today there is enormous demand for electronic mail that can deliver messages containing components such as HTML text documents, image files, sound, and even video data, in addition to regular text. However, such messages can be widely communicated only if all mail handling programs share a standard for constructing, encoding, and transporting such complex, multipurpose, messages.
The MIME protocol provides this common standard. MIME provides, as an extension upon the original RFC 822 mail protocol, an extensible format for including multimedia components within a mail message. Thus, MIME defines how to code the content, while RFC 822 specifies how to package the message and get it to its destination. MIME defines several document headers, placed inside the document, that specify such things as the nature of a message (multipart or single part), how the message parts are separated, the data content of each part, and the encoding scheme used to encode each part. The following sections summarize those features that are most important for Web applications. This is only a brief summary, however, and for further details you are referred to the relevant documentation (RFC 2045 through 2049) listed at the end of this appendix.
Of primary importance is the MIME content-type header. This should be familiar from elsewhere in the book, since this is the same header used to indicate the type of data being transferred using the HTTP protocol (see Chapter 9). Whenever a client requests a document from an HTTP server, the server first determines the type of the document, and then sends the appropriate content-type ahead of it. For example, if the file contained AIFF audio data, the server must send back the content-type header field:
Similarly, when a client browser uses the HTTP POST method to send data to a server, the data are preceded by a content-type header field that tells the server the format of the data being sent. The two supported types for posted FORM data are:
as discussed in Chapters 10 and 11, and also Chapter 6.
How do content-type headers work? Each header has a minimum of two parts, giving the data type and subtype. The syntax is:
The MIME specification defines type to be one of: image, audio, text, video, application, multipart, message, or x-arbitrary-name (these names, as with the string Content-Type:, are case-insensitive). The meanings of the first four are obvious, and indicate the overall type of the data. The application type is for other data (perhaps binary) that needs to be processed in a special way. This could be a program to run, or perhaps a PostScript document to be executed by a PostScript previewer. Multipart indicates a message containing more than one part, while message refers to an old-fashioned RFC 822 message. X-arbitrary-name (i.e., any name beginning with the string X-) is called an extension token, and refers to experimental data types. This lets you--or anyone else--create special MIME types that do not conflict with established ones. There are, in fact, many "experimental" MIME types in common use on the Web. Finally, two new basic types were recently introduced: World is used for Virtual Reality data (as in VRML) and for 2D/3D data sets used for generating 3D views; while chemical is designed for communicating information about chemical models and structures. Both of these are commonly seen with experimental names, as in x-world/* and x-chemical/*.
TIP: List of Web-relevant MIME Types
This Web site contains a detailed list of many of the common (and also not-so-common) MIME types, along with the most common filename extensions associated with those types. This list is available at: www.iangraham.org/books/html4ed/appb/mimetype.html
In the type/subtype string, the subtype gives the specifics of the content. Thus, text/html means a text file that is an HTML document, application/postscript means a PostScript file to be run through a PostScript interpreter, and so on. There are lots of content-types: The table at
lists those most important in Web applications. Subtypes can also be experimental extension types, such as the x-www-form-urlencoded subtype shown previously.
Note that, because of the nature of the HTTP client-server interaction, there are many content-types used by Web applications that are not commonly used in electronic mail.
Character Set Specifications for Text Types
Any text content-type--that is, text/* --can, in principle, take an optional charset parameter to specify the character set used in the text document--it's no use receiving a text file if the receiver does not know the relationship between the bytes and the desired characters. The format for including this parameter is
Content-Type: text/subtype; charset=char_set_name
where subtype is the text subtype (e.g., html or plain), and char_set_name is the name of the character set used in the document. Note how the semicolon (;) separates the text/subtype field from the charset parameter. Some possible values are US-ASCII and ISO-8859-1 (ISO Latin-1), ISO-8859-2, up to ISO-8859-9. (See Appendix A for more information on character sets.) Web applications currently assume the ISO Latin-1 character set by default, so this parameter is usually omitted.
HTML 4 defines the 16-bit Unicode character set as the base set for HTML documents. If documents are written using Unicode, then the correct charset value is either UCS-2 (16-bit encoding) or UTF-8 (8-bit encoding). See Appendix A for more information about Unicode. Some browsers, such as Netscape Navigator 4 and Internet Explorer 4, can handle these character sets. Unfortunately, a computer cannot display the desired characters unless you (the user) explicitly add the relevant character set's fonts to your machine--most machines do not come with built-in Unicode fonts.
NOTE: Many Browsers Do Not Understand Charset Parameters
At present, many Web applications ignore charset specifications, and assume that documents are encoded in ISO Latin-1. See Appendix A for more details.
HTML Level Specification
In principle, the text/html MIME type can take a version parameter. This optional parameter specifies the level of the HTML language used in the document. For example,
Content-type: text/html; version=3.2
indicates that the data are written using HTML 3.2. This parameter is largely unused by current Web applications.
Multipart MIME messages have recently taken on an important role in Web applications. This MIME type defines how multiple data parts can be included within a single message. These parts can be regular text files, HTML documents, or binary data (such as images), where the multipart specification defines how these messages are combined together, as well as how binary data are encoded within the message.
In a multipart message, the different parts are placed in a single message, one after the other, separated by a special divider. This divider or boundary is a text string, defined in the MIME multipart content-type header field that precedes the entire message. For example, for the multipart/mixed content-type (which refers to a multipart message containing a collection of unrelated parts of various types), the general form for the content-type field is
Content-Type: multipart/mixed; boundary=separatorstring
where separatorstring is a string of characters, guaranteed never to appear elsewhere in the message, that is used to separate the message parts.
The boundaries between message parts are then simple text lines consisting of the string
that is, the boundary string preceded by two dash characters. This string is followed by the content-type declaration for the specific part, which is in turn followed by a blank line, containing only a CRLF, to indicate the end of the headers and the start of the data. The end of one part of the data, and the beginning of the next part, is indicated by another string of the form --separatorstring. The end of the entire message is marked by the special string
The following simple example outlines such a message, where the strings CRLF denote the blank lines that follow the headers and precede the data:MIME-Version: 1.0 Content-type: multipart/mixed; boundary=23xx1211 CRLF --23xx1211 Content-type: text/html CRLF .... html document data .(first "part" of the message)... --23xx1211 Content-type: audio/aiff CRLF ..... audio data ..... (second "part" of the message).... --23xx1211--
This simple example omits several details, but illustrates the general approach. It contains two parts: a text file in HTML format, and an audio file in AIFF format. The MIME "multipart" header indicates that there is more than one component to the message, and specifies the string used to divide the message parts.
Important Multipart MIME Content-Types
Three multipart MIME types are of particular relevance on the Web. These are:
- Content-Type: Multipart/x-mixed-replace.
- This multipart model is employed in Netscape's multipart/x-mixed-replace MIME type, discussed at the beginning of Chapter 11 and illustrated in Figure 11.1. This type can be used to stream a continuous series of data from a server to the browser. Because the browser understands that the message is coming in multiple parts, it displays each part when it arrives, with the multipart divider string telling the browser where one part finishes and the next part begins.
- The multipart specification is also crucial to the multipart/form-data type (defined in RFC 1867--see the references at the end of this appendix), developed to support the uploading of complex FORM content, such as FORMs containing uploaded binary data files, to HTTP servers. When a FORM element specifies the POST method along with ENCTYPE="multipart/form-data", the data entered into the form's input elements are encoded into distinct parts of a multipart message, each input element giving rise to its own specific part. When the form is submitted, the data are sent to the server as a single message of the type multipart/form-data.
Note in particular that the use of an <INPUT TYPE="file" ...> input element forces the brower to use ENCTYPE="multipart/form-data", since this is the only mechanism that can encode a file and send it as a part of the FORM. This type is discussed briefly in Chapter 11.
- The multipart/related content type denotes a message containing parts that are related one to another. A typical example is a mail message consisting of an HTML document, along with all the images that appear inline in the document. In this case, the mail message must contain all the parts, but must also support URLs that link between the parts, so that the document can contain URLs referencing the images lying in the same message.
The specification for doing this is found in the new MHTML (MIME-HTML, or M-HTML) specification, defined in RFC 2110. Figure B.1 illustrates one case from this specification: Here, the new Content-base header indicates the base from which the document and its parts came. The browser uses this content-base to locate all the related parts, including the image file included as the second part of the message. This mechanism is largely used by the Netscape Navigator 4 mail client, when composing HTML mail messages.
Figure B.1 An illustration of a simple multipart/related message containing an HTML document and a related image file. Comments are in italics.
regular mail headers .... (see RFC 822) Mime-Version: 1.0 Content-Base: http://www.utoronto.ca/ian/ Content-Type: Multipart/related; boundary="1131012312311412"; type=Text/HTML --1131012312311412212 Content-Type: Text/HTML; charset=ISO-8859-1 ... here is the example document, which contains reference to the image file to be inlined when the document is displayed: <IMG SRC="/images/ians-mug.jpeg" ALT="UGLY Picture!"> The browser uses the Content-base header to recognize that the image is actually included below, in the next part of the document; --1131012312311412 Content-Location: /images/ians-mug.jpeg Content-Type: image/jpeg Content-Transfer-Encoding: BASE64 APlGODlhGAGgAPEAAP/////ZRaCgoAZZDCH+PUNvcHlyaWdodCAoQykgMTk5 AQDVK32yilpdj1ad1sfg11l6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A and so on -- a BASE64 encoded image ... --1131012312311412--
There are many other mechanisms allowed by the MHTML specification, including the use of cid and mid URLs (see Chapter 8) to reference specific parts within the message, or even specific parts within another mail message. See RFC 2110 for details.
How a Server Determines MIME Content-Type
For the server to be able to send a content-type header, it must know the type of the data being returned. When a server is returning actual data files, this type is determined via conventions for the filename suffixes or extensions--servers assume that the suffix defines the type of a document. For example, files with the extension .mpeg are usually assumed to be MPEG movies, while files ending in .html are assumed to be HTML documents, and so on. On some servers (and because of the limits of Windows 3.1), these names are often shortened to three letters, for example, .mpg for MPEG movies and .htm for HTML documents.
The actual relationship between filename suffixes/extensions and MIME types is configurable, and can be changed by modifying the server's configuration files. Thus, when the server administrator defines a new type of data on a server, for example Kodak Photo-CD images, he or she must define an extension to use for such files (e.g., .pcd) and configure the server to associate the MIME type (e.g., image/x-photo-cd) with this extension. The server administrator can also associate multiple extensions with the same MIME type (e.g., .html and .htm both corresponding to HTML documents). Of course, it is then up to the author, when placing documents on the server, to ensure that the documents use the extensions corresponding to each document's content.
Default Types for Unknown Filename Extensions
If the server does not know the type of a file, it assumes a default content-type value, often text/plain. However, this default can be changed to another value, and some servers are configured to send unknown data out as type application/octet-stream. This corresponds to unidentified binary data--a browser will generally prompt the user to save the file to disk.
If a browser receives a file from an HTTP server, it is explicitly told the content-type by the server's response header. With FTP or local file access, this information is not available, and the browser must itself determine--or guess at--the file type. Again, this is done by the filename extension. To support this, Web clients also have a database matching filename extensions to data types, which they use in the absence of any other content-type information.
The location of this database varies from browser to browser, but in most cases this database can be accessed and modified from within the browser via pull-down menus.
How Browsers Handle Different Content-Types
When a browser receives data, it checks the MIME type to see if the browser itself can view the indicated data type. If it cannot, it then looks for an alternative mechanism for displaying the data. If the data were accessed via an anchor element, the browser checks to see if there is a helper application (a program separate from the browser) to which the data can be sent. If there is no such application, the browser informs the user of its predicament, and asks what it should do (save the file to disk, cancel the download, etc.).
If the data were accessed as an embedded object (via EMBED or OBJECT elements), the browser searches the user's machine for an appropriate plug-in module. If no appropriate plug-in is available, the browser informs the user of the problem, and asks the user what to do (save the file to disk, search the Web for an appropriate plug-in, cancel the download, etc.).
Follow the above link to view the references
|The HTML 4.0 Sourcebook||© 1995-1998 by Ian S. Graham|