Content-type: text/htmland it may also be text/plain, image/gif, audio/mp3, audio/x-pn-realaudio, chemical/x-xyz, etc. The benefit of doing this is that after knowing the stream type in the beginning, the receiving end could process the stream "on-the-fly" without much buffering, which is clealy the case in text/plain, audio/mp3 and audio/x-pn-realaudio, and is partially the case for text/html.
Let me presume the browser to be Netscape. Depending on the header declaration, some of the most common streams are handled internally by Netscape itself, such as text/plain, text/html, image/gif, image/jpeg.
The next level is the so-called plug-ins, where the viewers are not the softwares of the Netscape company, but are slightly re-fitted to appear in the same window. An example of this is the Adobe Acrobat Reader -- apparently what happens is that Adobe write a subroutine library, which Netscape dynamically load in and execute when such need arises. The Mime types to be handled by plug-ins are specified in ~/.netscape/plugin-list.
The last level is the so-called external helpers: the Netscape company has no relation with the authors of the helpers. The helpers appear in separate windows, and it is the burden of the user to install the helpers and to make them work. Data flow is achieved through a file (perhaps RAM DISK) denoted by %s. After some trials, I find that specifications of helpers are in a file ~/.mailcap, where "g", "rasmol" etc. are scripts and binaries installed by myself and made executable in the parent shell of Netscape (PATH environmental variable). chemical/x-pdb and chemical/x-xyz are rather esoteric Mime types (the latter one is defined purely by myself), but as long as some web servers are willing to serve them (declare the packet header as chemical/x-pdb), then my Netscape browser will save the stream to a temporary file and then pass on to "rasmol". Stdout and stderr are directed to popout dialog boxes, which is quite annoying sometimes.
Before thinking about the web server, let us consider a peculiar case first, which is "file:/" (sometimes "http://localhost/" is equivalent to "file:/") locator. Clearly, without running or even installing web servers like Apache, one can still view what is in the local file system by "file:/". Thus, it is the sole responsibility of Netscape, not any server, to distinguish the Mime types of local files. For instance, it should be able to classify a local file "file:/Home/Sun/Archive/NetApp/tang.mp3" as of Mime type audio/mp3 (and then since the type isn't internal or appears in ~/.netscape/plugin-list, but in ~/.mailcap, Netscape correctly call the external helper "x11amp"). How does Netscape do that?
This specification clearly resides in the local machine. As it happens, there is a standard system Mime type specification /etc/mime.types in RedHat Linux. Is it the file controlling the behavior of Netscape? As I changed /etc/mime.types as root, I found that no, it doesn't. /etc/mime.types may be useful for many things, but it does not control the behavior of Netscape (when you think about it, Netscape tends to a user-dependent, not system-dependent application). The real controller turns out to be ~/.mime.types, whose first line is a "magic number" signifying what follows are the private properties of the Netscape browser. After I added audio/mp3, audio/m3u, chemical/x-pdb, chemical/x-xyz to ~/.mime.types, the "file:/" locator works beautifully with ~/.mailcap and my helpers for these local files.
Now we should consider the server side. There is a real simple
solution for the Apache server:
one just use "AddType" command in the /etc/httpd/conf/srm.conf server configuration
file,
#restart the server using script httpd.restart, and then reload the page. When the server doles out packets, all files with suffix ".xyz" are preceded by headersmy own-defined MIME "content headers" AddType chemical/x-xyz .xyz .XYZ AddType chemical/x-pdb .pdb .PDB .ent AddType audio/mp3 .mp3 AddType audio/m3u .m3u # the file type association must only contain one "."
Content-type: chemical/x-xyzwhich you can change to anything you like (Content-type: chemical/x-zyx, say) as long as the browser on the other end understands (by its own ~/.mailcap). It works as simple as that.
Now, if you don't want to use "AddType", which indiscriminately turns all files with certain suffixes to corresponding Mime type packets, one can do something more complicated by modifying a configuration file /etc/httpd/conf/magic, which distinguishes Mime types by certain "physical characteristics", like the first few "magic-number" bytes. /etc/httpd/conf/magic seems to work side by side with /etc/mime.types. Unless it is absolutely necessary, I would use "AddType" instead of changing /etc/httpd/conf/magic and /etc/mime.types.
Following are various Mime type samples. It seems that UNIX servers tend to call certain files x-*, like audio/x-mp3, while other servers just call them audio/mp3. For safety's sake, I declared both in ~/.mailcap. Also, "xv" and "xanim" are very versatile programs, so I used them to "catch all", which is a good strategy.
