oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Apache Web Serving with Jaguar, Part 2

by Kevin Hemenway coauthor of Mac OS X Hacks

Editor's note: In his rewritten-for-Jaguar previous article, Kevin Hemenway showed you how to easily start serving web pages from your Mac OS X computer. In this tutorial, he explores the world of CGI access. To gain the most from what Kevin has to offer here, you'll need some familiarity with the Terminal application.

If you haven't explored that feature yet, I recommend that you first read our Terminal companion article, "Learning the Terminal in Jaguar." Once you're comfortable using the command line, you can return here and dig deeper into Apache.

Learning a Bit More About Apache

So, after the work we did in the last article, we've got a prettier URL, but still a rather boring site. We need features to impress the boss, and to turn them on, we're going to have to start fiddling with Mac OS X's Terminal. We're going to assume you know how to edit and save files via the command line, either through a native shell editor (like vi or emacs) or a GUI editor, such as BBEdit. We prefer BBEdit 7.0 and its shell utility (which you can install via Preferences->Tools->Install "bbedit" Tool).

Before we turn on features, we need to know where Apache's configuration file lives. To find out, we'll query the Apache web server itself, so open a Terminal and enter the following command line:

httpd -V

This will spit out a screen of information specific to your Apache installation (this command will work with any Apache install--for Mac, Linux, or Windows). On an OS X 10.2.4 machine, we find out that we're using Apache 1.3.27:

Server version: Apache/1.3.27 (Darwin)
Server built:   10/16/02 21:48:47

As well as where the server configuration and error log is located:

-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
-D DEFAULT_ERRORLOG="/var/log/httpd/error_log"

Along with the default error log (which is insanely useful for debugging), Apache also writes to /var/log/httpd/access_log, which keeps track of every request your Apache web server has received. Note: In previous versions of the Apple-supplied Apache, a DEFAULT_XFERLOG would also have been defined in the output of httpd -V, and it'd point to the access_log we just mentioned. This functionality has since been moved to a CustomLog statement within the Apache configuration file. If you have no clue what I'm talking about, that's just fine, too--this is only useful to nitpickers or long-time OS X web servers.

Mac OS X Hacks

Related Reading

Mac OS X Hacks
100 Industrial-Strength Tips & Tricks
By Rael Dornfest, Kevin Hemenway

Learning About CGI Access

It's now time to fiddle with the most common feature available to a web server: CGI. Without getting overly esoteric, CGI allows us to install thousands of different scripts that can be accessed through a normal web browser. CGI scripts are often written in Perl (also installed by default under OS X), and can allow users to access databases, use interactive forms, chat on bulletin boards, and so on.

Apache comes with two simple scripts that can verify CGI is configured correctly. Before we test them, however, let's see what we can learn from the Apache configuration file. To start, open up your config file in your favorite text editor (this example assumes BBEdit):

bbedit /etc/httpd/httpd.conf

Be forewarned: the Apache configuration file is rather large, but also well-documented. Take its introductory warning to heart: "Do NOT simply read the instructions ... without understanding what they do. They're here only as hints or reminders. If you are unsure consult the online docs. You have been warned." The online docs are available at the Apache web site.

The quickest way to find and learn about the Apache configuration file is to search for the feature you want to enable. In our case, we'll start looking for "CGI." The first entry we find is:

LoadModule cgi_module libexec/httpd/

Followed shortly by:

AddModule mod_cgi.c

You'll see a number of these lines within the Apache config file. If you've ever worked with a plugin-based program, you'll easily recognize their intent--these lines load different features into the Apache web server. Apache calls these "modules," and you'll see a lot of the module names prefixed with mod_, such as mod_perl and mod_php. Lines that are commented out (that is to say, lines that are prefaced with a # character) are inactive.

Because our CGI lines are already active (they're not prefaced with #), we'll continue searching:

ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"

<Directory "/Library/WebServer/CGI-Executables">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all

The ScriptAlias directive allows us to map a URL to a location on our hard drive. In this case, the ScriptAlias line is mapping a URL of to the hard drive location of /Library/WebServer/CGI-Executables/. If you browse to that folder, you'll see the two CGI scripts I mentioned above: printenv and test-cgi. The <Directory> block isn't that important right now, so we'll move on to our next search result:

# AddHandler cgi-script .cgi

This is your first major decision concerning your Apache installation. When a certain directory has been ScriptAliased (as our CGI-Executables directory has, above), the files within that directory are always executed as CGI scripts. If the files were moved out of that directory (say, into our DocumentRoot), they'd be served as normal text files.

By uncommenting the AddHandler line, you're telling Apache to execute and run any file that ends in .cgi. This can happen from any directory and from any user, and is often considered a security hazard (for example, if you had an anonymous FTP server that uploaded directly into your web space, a malicious user could upload a damaging .cgi script, then execute it through their browser).

Pages: 1, 2

Next Pagearrow