MIME Tutorial
Applies to: Navigator and Communicator (all versions)Operating Systems: MacOS, UNIX, Windows 3.x, Windows 95, and WindowsNT
INTRODUCTION. MIME (Multipurpose Internet Mail Extensions) is a term that crops up quite often in the context of Internet mail, news and even World Wide Web. Understanding some basic ideas about how data is sent over the Internet and how the recieving software understands what the data represents will help in getting the most from mail, news and browser software. In this document, the basic use of MIME will be presented in hopes that a simple approach can answer most questions that arise.
WHAT IS MIME? On the Internet, data is sent as 8 bit bytes. The receiving software collects these bytes and assembles them in the proper order. Now the question becomes, "What do these bytes represent?" Are they text? Are they a picture? Are they a sound? How is it possible to know what they mean? Suppose, in addition to the bytes that contain whatever it is, an additional few bytes are sent along saying what the data is. If this is done, the recieving software or person knows what is in the bunch of bytes that make up the message. This is what MIME does. It tells what is in a message so that the message contents can be used in an appropriate way.
WHAT DOES MIME LOOK LIKE? A good place to begin is news and mail because in news and mail, it is most easily seen. If you look at a mail message, it has a lot of "stuff" on the front. Here is an example of the "stuff."
From - Tue Apr 1 09:39:21 1997
Received: from cantor (ppp-phx-15.futureone.com [207.2.43.15])
by future.futureone.com (8.8.2/8.8.0) with ESMTP id JAA23032 for
; Tue, 1 Apr 1997 09:36:14 -0700 (MST)
Received: from cantor (localhost [127.0.0.1]) by cantor (8.7.4/8.7.3)
with SMTP id JAA00568 for ; Tue, 1 Apr 1997
09:38:57 -0700
Sender: chrlsim@futureone.com
Message-ID: <33413A21.412D43B3@futureone.com>
Date: Tue, 01 Apr 1997 09:38:57 -0700
X-UIDL: 859912584.000
From: Chuck Simmons
Organization: Organized? You jest!
X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.0 i486)
MIME-Version: 1.0
To: Chuck Simmons
Subject: Test of from
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Status: U
X-Mozilla-Status: 0001
Content-Length: 367
That's a lot of "stuff" but there are only two items of interest in our
look at MIME. The two items are Content-Transfer-Encoding: and
Content-Type:. For now, our interest will be in Content-Type:. this
item tells us what kind of data was received. In this message, the
data is "text/plain." That seems to be clear enough. The "text/plain"
is the MIME type for this message. The "text" part is called the MIME
type and the "plain" is the subtype. The type and subtype are always
separated by a "/" character. The "type" is broad. There are many
kinds of text. The subtype is specific. There is only one kind of
plain text. (A character set may be specified but this is not important
to this discussion.)
WHAT ARE SOME COMMON MIME TYPES?
text/plain as in the usual mail or news message.
text/html HTML text as on the World Wide Web.
image/jpeg a common image format.
image/gif another common image format.
application/octet-stream unknown type, any kind of data as bytes.
audio/midi midi music format for synthesizers.
audio/x-midi an alternate for the above.
application/ps indicates PostScript document.
The above list has only a few of the many recognized MIME types. There
are lists that can be found on the World Wide Web that have many more.
Here is one list you can look at,
http://home.netscape.com/assist/helper_apps/mimeindex.html.
IS THE DATA READY TO USE IF THE MIME TYPE IS KNOWN? In mail and news, often it is not. On the World Wide Web it usually is. This is where Content-Transfer-Encoding: comes in. On the World Wide Web, data is sent as 8 bit bytes so no encoding is needed. Mail and news are most generally 7 bits so somehow, 8 bit bytes have to be crammed into 7 bit chunks. The Content-Transfer-Encoding: tells how this was done. The common encodings are uuencode and base64 but there are others.
Thus to make the data ready to use, the Content-Type: must be known and the Content-Transfer-Encoding:, if any, must be known. When both are known many Internet applications will decode the data and send it to an appropriate viewer, other application or to a selected file on disk.
WHERE CAN I FIND OUT ABOUT NETSCAPE AND MIME? Probably the best place to find out about how Netscape handles MIME messages is in http://home.netscape.com/eng/mozilla/3.0/relnotes/unix-3.0.html#MIME. The discussion here is rather detailed but the introductory information above should make it possible to read the document and understand the main ideas.
WHAT ABOUT MIME ON THE WORLD WIDE WEB? This question cannot be answered without considering a particular browser so our investigation will be directed at Netscape products.
The World Wide Web server, when it answers a request for data from a browser, sends some information before it sends the requested data. Here is an example.
HTTP/1.0 200 OK
Date: Thu, 10 Apr 1997 00:04:30 GMT
Server: Apache/1.1.0
Content-type: text/html
Set-Cookie: Apache=localhost349860630670983; path=/
Content-length: 2719
Last-modified: Fri, 13 Dec 1996 18:45:59 GMT
Notice the "Content-type: text/html." This tells the browser that the
data which follows should be interpreted as HTML or "web text."
Here is another example.
HTTP/1.0 200 OK
Date: Thu, 10 Apr 1997 00:08:51 GMT
Server: Apache/1.1.0
Content-type: audio/midi
Set-Cookie: Apache=localhost244860630931311; path=/
Content-length: 30178
Last-modified: Wed, 19 Jun 1996 23:28:43 GMT
In this case the browser is told to expect a music synthesizer file. It
can use a plug-in, launch a helper application or offer a dialog box
where the user may select a way to handle the data.
WHY DOESN'T NETSCAPE RECOGNIZE *.BLAH, IE DOES? Netscape is designed to function properly on a network having various platforms or operating aystems. Strictly, *.blah means nothing across the various platforms that haunt the Internet. Netscape has chosen to trust the Content-type: and ignore the file extension. Microsoft Internet Explorer tends to ignore Content-type: and make a guess about what may be found in the transferred data according to the file extension in the request. The use of Content-type: to identify the message contents is an important part of World Wide Web technology. It makes possible more general methods of content delivery while satisfying the requirements of a heterogeneous network. Expected client software behavior with respect to various header items in HTTP is well documented in the various RFC's. In particular, the role of the Content-type: as the means of identifying data types on the World Wide Web is clearly spelled out in these documents.
WHAT ABOUT FTP? FTP differs from HTTP in a number of ways but in particular, an FTP server does not send a Content-type header. Thus if a file transferred via FTP is to be handled on the client system by a special application, the selection of the application must be based on the file extension. Because of system differences, the selection may not be a useful one. Fortunately, should the selection be faulty or it is desired to download the file anyway, shift click or some other facility is generally provided to make download possible. After download, the user may decide the proper disposition of the file perhaps renaming it to take advantage of an appropriate file association if any.
WHY DOES AN ATTACHMENT APPEAR AS RANDOM TEXT? This may happen if the Content-type: is not correct for the data. For example, if the Content-type: type is given as text/plain when it should be image/jpeg, Netscape will assume the text/plain is correct and display the encoded data. In this case, save the attachment to disk and use decoding software to obtain the image file in usable form. It may also happen that incorrect Content-Transfer-Encoding: will fool Netscape and cause a broken image icon to appear or simply text as above.
WHAT IF Content-Type: IS MISSING? In this case, Netscape will assume that encoded data may exist in the message and may or may not succeed in finding and decoding such information. In such a case, saving the message to disk and applying decoding software may work.
CAN I SEND A UUENCODED DOCUMENT? Probably but it may depend on file system naming conventions. In Windows 95/NT, naming the uuencoded file with an extension like .jpg.uu or in UNIX .jpg.uue will generally send the information correctly. Unfortunately, this technique is limited to file systems in which the "double" extension is valid in a file name.
HOW DO I FIND OUT MORE? Use a search engine. I did in researching this document. RFC documents are the last word on all Internet issues. For MIME, RFC 2045: (MIME) "Part One: Format of Internet Message Bodies" and RFC 2046: (MIME) "Part Two: Media Types" are the most important. Using a search engine you can find detailed documents on every aspect of the Internet. In most cases, though, the basic ideas I have presented should serve.
SOME INFORMATION ON CGI
CGI CONSIDERATIONS. CGI (Common Gateway Interface) is a way for a web author to use a program on the web server to transfer data to a browser. The server will supply part of the HTTP response header but the CGI program must supply the rest as needed. Examples of header information that may be supplied by a CGI program are:
Content-type: text/html
Location: http://somewhere.domain/.
When used, these must be followed by two newlines to alert the browser
that the header is complete and data, if any, will follow. The CGI
application must send data or redirect the browser. The first example
above is a case in which data will follow. The second example is a
redirect to http://somewhere.domain/. Many good examples of CGI
applications can be found on the World Wide Web. A visit to
http://www.yahoo.com/
will turn up many good references and working applications.
HOW DO I TELL THE BROWSER WHAT THE FILE EXTENSION IS? This can be handled with a little trick. If the URL you are using looks like:
http://my.domain/cgi-bin/my_CGI_application
and the file extension is .blah, use:
http://my.domain/cgi-bin/my_CGI_application/x.blah
instead. This will get the file extension correct in some browsers.
HOW CAN I PRESERVE THE FILE NAME IN CGI? This is a variation of the above. You will probably have to redirect to another CGI application with something like:
location: http://my.domain/cgi-bin/my_CGI_application_2/my_file.blah
where my_file.blah is the desired file name. The application,
my_CGI_application_2, can read the file name from the CGI environment
variable PATH_INFO and send my_file.blah with an appropriate
Content-type:.
Chuck Simmons
