Editor's note: In this third and final batch of recipes from the recently released Apache Cookbook, authors Rich Bowen and Ken Coar provide solutions to problems related to authentication, symbolic links, and the ever-troublesome trailing slash. And if you missed any recipes from the first two batches, we've provided links and descriptions to those recipes at the end of the page. Enjoy.
You wish to proxy content from a server, but it requires a login and password before content may be served from this proxied site.
Use standard authentication techniques to require logins for proxied content:
ProxyPass "/secretserver/" "http://127.0.0.1:8080" <Directory "proxy:http://127.0.0.1:8080/"> AuthName SecretServer AuthType Basic AuthUserFile /path/to/secretserver.htpasswd Require valid-user </Directory>
This technique can be useful if you are running some sort of special-purpose
or limited-function web server on your system, but you want to apply Apache's
rich set of access control and its other features to access it. This is done by
ProxyPass directive to make the special-purpose server's URI
space part of your main server, and using the special
<Directory> container syntax to apply Apache settings
only to the mapped URIs.
You wish to balance the security needs associated with symbolic links with the performance impact of a solution, such as using
Options SymLinksIfOwnerMatch, which causes a server slowdown.
For tightest security, use
Options SymlinksIfOwnerMatch, or
Options -FollowSymLinks if you seldom or never use symlinks.
For best performance, use
Symbolic links are an area in which you need to weigh performance against security and make the decision that makes the most sense in your particular situation.
In the normal everyday operation of a Unixish operating system, symbolic links are considered to be the same as the file to which they link.  When you
cd into a directory, you don't need to be aware of whether that was a symlink or not. It just works.
Apache, on the other hand, has to consider whether each file and directory is
a symlink or not, if the server is configured not to follow symlinks. And,
Option SymlinksIfOwnerMatch is turned on, Apache not only has to
check if the particular file is a symlink, but also has to check the ownership
of the link itself and of the target, in the event that it is a symlink. While
this enforces a certain security policy, it takes a substantial amount of time
and so slows down the operation of your server.
In the tradeoff between security and performance, in the matter of symbolic links, here are the guidelines.
If you are primarily concerned about security, never permit the following of
symbolic links. It may permit someone to create a link from a document directory
to content that you would not want to be on a public server. Or, if there are
cases where you really need symlinks, use
Options SymlinksIfOwnerMatch, which requires that someone may only link to files that they own and will presumably protect you from having a user
link to a portion of the filesystem that is not already under their control.
If you are concerned about performance, then always use
Options FollowSymlinks, and never use
Options FollowSymlinks permits Apache to follow symbolic links in the manner of most Unixish applications - that is, Apache does not even need to check to see if the file in question is a symlink or not.
 Of course, this is not true at the filesystem level, but we're just talking about the practical user level.
Loading a particular URL works with a trailing slash but does not work without it.
Make sure that
ServerName is set correctly and that none of the
Alias directives have a trailing slash.
The "trailing slash" problem can be caused by one of two configuration
problems: an incorrect or missing value of
ServerName, or an
Alias with a trailing slash that doesn't work without it.
An incorrect or missing
ServerName seems to be the most prevalent cause of the problem, and it
works something like this: when you request a URL such as http://example.com/something, where something is the name of a directory, Apache actually sends
a redirect to the client telling it to add the trailing slash.
The way that it does this is to construct the URL using the value of
ServerName and the requested URL. If
ServerName is not set correctly, then the resultant URL, which
is sent to the client, will generate an error on the client end when it can't
find the resulting URL.
If, on the other hand,
ServerName is not set at all,
Apache will attempt to guess a reasonable value when you start it up. This will
often lead it to guess incorrectly, using values such as 127.0.0.1 or localhost,
which will not work for remote clients. Either way, the client will end up
getting a URL that it cannot retrieve.
In the second incarnation of this problem, a slightly malformed
Alias directive may cause a URL
with a missing trailing slash to be an invalid URL entirely.
Consider, for example, the following directive:
Alias /example/ /home/www/example/
Alias directive is very literal, and aliases URLs starting with /example/, but it does not alias URLs starting with /example. Thus, the URL http://example.com/example/ will display the default document from the directory /home/www/example/, while the URL http://example.com/example will generate a "file not found" error message, with an error log entry that will look something like:
File does not exist: /usr/local/apache/htdocs/example
The solution to this is to create
Alias directives without the trailing slash, so that they will work whether or not the trailing slash is used:
Alias /example /home/www/example
Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.
Ken Coar is a member of the Apache Software Foundation, the body that oversees Apache development.
Return to the Apache DevCenter.
Copyright © 2009 O'Reilly Media, Inc.