Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm just about to launch a new Django website (RedHat EL4, Apache 2.0.52, Django 1.1, mod_wsgi), transitioning from a basic static-html and php site. As it's currently configured, Django handles every request on the new site, starting from the site root (i.e. is processed by Django).

The old site had a PhpBB forum set up at I'm trying to figure out how (or if) I can get the forum system to live in the same place on the new site. So, anything under is handled by PhpBB and everything else is handled by Django.

I feel like the Apache 'Location' directive is the tool to use, but I'm not getting enough specific advice from the Apache docs and Google. I'm reasonably familiar with Apache conf files, but I haven't had to do this type of thing before. Thanks for any suggestions.

share|improve this question
up vote 1 down vote accepted

I have static files served from my host via the following in my apache config:

  Alias /media /sites/
  <Location /media>
    Order allow,deny
    Allow from all

With that, Apache deals with the alias before it ever gets to Django. I assume you will just need to have php enabled for it to work against that directory.

UPDATE As per Graham's comment below. Look at the "What to use When" section in

What to use When

Choosing between filesystem containers and webspace containers is actually quite easy. When applying directives to objects that reside in the filesystem always use or . When applying directives to objects that do not reside in the filesystem (such as a webpage generated from a database), use .

It is important to never use when trying to restrict access to objects in the filesystem. This is because many different webspace locations (URLs) could map to the same filesystem location, allowing your restrictions to be circumvented. For example, consider the following configuration:

<Location /dir/>
Order allow,deny
Deny from all

This works fine if the request is for But what if you are on a case-insensitive filesystem? Then your restriction could be easily circumvented by requesting The directive, in contrast, will apply to any content served from that location, regardless of how it is called. (An exception is filesystem links. The same directory can be placed in more than one part of the filesystem using symbolic links. The directive will follow the symbolic link without resetting the pathname. Therefore, for the highest level of security, symbolic links should be disabled with the appropriate Options directive.)

If you are, perhaps, thinking that none of this applies to you because you use a case-sensitive filesystem, remember that there are many other ways to map multiple webspace locations to the same filesystem location. Therefore you should always use the filesystem containers when you can. There is, however, one exception to this rule. Putting configuration restrictions in a section is perfectly safe because this section will apply to all requests regardless of the specific URL.

share|improve this answer
I think that's going to work like a charm. You're a life saver. – Bill Sep 2 '10 at 8:55
It is arguably bad practice to use Location directory like that for URL. Use Directory directive against the file system directory instead as is more specific. – Graham Dumpleton Sep 3 '10 at 3:49
I've updated the answer with a link to and a paste of a small section the relevant apache documentation on Location vs. Directory and it's implications. – davey Sep 3 '10 at 6:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.