When a WWW server returns a document to a WWW client, it
specifies the type of the data contained in the document using a
MIME content type (see section ). The client will be
able to handle some MIME content types itself, but it's unlikely to
be able to handle all possible content types, so it will have to feed
the data to another program that can.
Most clients come with a built in set of default programs to handle specific common content types, but you may also want to add a new content type, or simply tell the client to use a different program to display a particular content type. In this case, you will have to tell the client which application to run to view that particular content type.
For example, if an HTTP request returns the MIME content type
application/postscript, your client needs to know that it should
launch the postscript previewer, say ghostscript.
This is done using a ``mailcap'' or mail capability file,
taken from the
MIME standards (see RFC 1521 and section ).
Here is an example mailcap file:
# any line with a '#' at the beginning is a comment # This causes us to use mpeg_play_x to view MPEG video/mpeg; mpeg_play_x %s # This is our default audio player program audio/basic; showaudio %s # This is useful for the audio/x-illustrated; iaunpack %s
Note that such a personal customisation is usually in addition to the system-wide default mailcap.
A very powerful, and dangerous feature of some clients is the ability to have the server cause the execution of arbitrary programs at the client end (this is the exact inverse of CGI, which is discussed in chapter 5). This can be done by the server returning a MIME content type `` application/x-csh'' and a mailcap file with this appropriately configured:
# Danger Danger Danger - extreme security loophole potential!!! application/x-csh; csh -f %s
A safer option for servers providing such active information is to use languages such as perl or Tcl which are available in safe forms where the interpreter can check for file access or execution of specific commands.