httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@nueva.pvt.k12.ca.us>
Subject Re: For review... <Location> patch
Date Wed, 03 Apr 1996 23:36:22 GMT
On Wed, 3 Apr 1996, Aram Mirzadeh wrote:

> I like the idea, but couldn't this have been implemented in the <directory>
> directive?  I know with all these new directives and such the configuration
> files are just going to get more and more cryptic, (it's never reach
> sendmail)

The short answer is no.

The long answer is yes, but would you really want to? I don't see any
compelling reason to use <Directory> over again, for what amounts to a
very different thing, sort of. Here are some reasons why not:

1. Well, it's not a directory. That's pretty simple. There is no
filesystem element to a URL, so you can't very well call it one.

2. It's a tad confusing. Right now, <Directory> directives are read
from most general to most specific (from / up to the directory the
file's in). But URL-related directives have to be parsed either before
or after all the directory-related ones. Using the same name for both
could rather cause confusion, because it wouldn't work as expected.

3. Perhaps most importantly, how do you distinguish between the two
types? If I put in <Directory /users>, am I protecting the /users
directory, or a URL beginning with /users? Many systems have both. To
deal with this, and to not upset existing configurations, we'd have to
hack in some way to specify an entry as a URL, like <Directory
URL:/users>, and IMO, it's much nicer to use a seperate directive,
<Location>.

I agree that the directive set should be kept as limited as possible,
but I think this is defnitely one case where a new directive is
needed. Besides, Apache currently has (by my count) 136 directives. If
you wanted to keep it limited to a small number, I think it's a bit
too late now.

--

Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
URL: http://www.nueva.pvt.k12.ca.us/~akosut/
Lefler on IRC, DALnet <http://www.dal.net/>



Mime
View raw message