| Previous | Table of Contents | Next |
A fundamental element of the HTTP protocol, and the reason why the Web was so natural as a home for multiple media formats, is that every data object transferred through HTTP had an associated MIME type.
NOTE: The origins of MIME (Multipurpose Internet Mail Extensions) lie in an effort to standardize the transmission of documents of multiple media through e-mail. Part of the MIME specification was that e-mail messages could contain meta-information in the headers identifying the data being sent. One type of MIME header is Content-Type, which states the format or data type the object is in. For example, HTML is given the label “text/html,” and JPEG images are given the label “image/jpeg.”
ON THE WEB:
A registry of MIME types is maintained by the Internet Assigned Numbers Authority at this site: http://www.isi.edu/div7/iana/
When a browser asks a server for an object, the server gives that object to the browser and states what its Content-Type is. That way, the browser can make an intelligent decision about how to render the document. For example, it can send it to an image program, to a PostScript viewer, or to a VRML viewer.
What this means to the server maintainer is that every object being served out must have the right MIME type associated with it. Fortunately, there has been a convention of expressing data type through two-, three-, or four-letter suffixes to the filename—for example, foobar.gif is most likely to be a GIF image.
What the server needs is a file to map the suffix to the MIME content type. Fortunately, Apache comes with such a file in its configuration directory—a file named mime.types. The simple format of this file consists of one record per line, where a record is a MIME type and a list of acceptable suffixes. Although more than one suffix may map to a particular MIME type, you can’t have more than one MIME type per suffix. You can use the TypesConfig directive to specify an alternative location for the file.
The Internet is evolving so quickly that it would be hard to keep the mime.types file completely up-to-date. To overcome this difficulty, you can use a special directive, AddType, which can be put in the srm.conf file as follows:
AddType x-world/x-vrml wrl
Now, whenever the server is asked to serve a file that ends with .wrl, it knows to also send a header like the following:
Content-type: x-world/x-vrml
Thus, you don’t have to worry about reconciling future distributions of the mime.types file with your private installations and configuration.
As you’ll see in later pages, AddType is also used to specify “special” files that get magically handled by certain features within the server.
A sister to AddType is AddEncoding. Just as the MIME header Content-Type can specify the data format of the object, the Content-Encoding header specifies the encoding of the object. An encoding is an attribute of the object as it’s being transferred or stored; semantically, the browser should know that it has to “decode” whatever it gets, based on the listed encoding. The most common use is with compressed files. For example, if you have
AddEncoding x-gzip gz
and if you then access a file named myworld.wrl.gz, the MIME headers sent in response will look like the following (MIME headers of this format accompany every transfer over the Web; these headers are not displayed by the browser but are used to define how to handle the incoming file):
Content-Type: x-world/x-vrml Content-Encoding: x-gzip
And any browser worth its salt will know, “Oh, I have to decompress the file before handing it off to the VRML viewer.”
NOTE: With Apache 1.3, the optional module mod_mime_magic (if compiled in) can analyze the contents of a file and assign it a file type extension if one isn’t present. This module is based on a free version of the UNIX file command.
The Alias, ScriptAlias, and Redirect directives—all denizens of srm.conf and all implemented by the mod_alias.c module—allow you to have some flexibility with the mapping between URL-Space on your server and the actual layout of your file system.
Basically, any URL that looks like http://myhost.com/x/y/z isn’t required to map to a file named x/y/z under the document root of the server, acting much like a symbolic link. For example:
Alias /path / /some/other/path/
The preceding directive takes a request for an object from the mythical subdirectory /path under the document root and maps it to another directory somewhere else entirely. For example, a request for
http://myhost.com/statistics/
might normally go to document root /statistics, except that for whatever reason you wanted it to point somewhere outside the document root (for example, /usr/local/statistics). For that you’d have to use the following command:
Alias /statistics/ /usr/local/statistics/
To the outside user, this would be completely transparent. If you use Alias, it’s wise not to alias to somewhere else inside the document root. Furthermore, a request like
http://myhost.com/statistics/graph.gif
would get translated into a request for the file
/usr/local/statistics/graph.gif
ScriptAlias is just like Alias, with the side effect of making everything in the subdirectory by default a CGI script. This might sound a bit bizarre, but the early model for building Web sites had all the CGI functionality separated into a directory by itself, and referenced through the Web server as shown in the following:
http://myhost.com/cgi-bin/script
If you have in your srm.conf file
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/
then the preceding URL points to the script at /usr/local/etc/httpd/cgi-bin/script. As you’ll see in a page or two, there’s a more elegant way to specify that a file is a CGI script to be executed.
| Previous | Table of Contents | Next |