httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Bad choice of directory names for info- & status-modules
Date Wed, 24 Jul 1996 18:50:51 GMT
On Wed, 24 Jul 1996, Robert S. Thau wrote:

>   Of course it is, that's what it *does*. Just like <Directory>, it looks
>   for files (or in this case, URLs) that match the given prefix. Except that
>   <Directory> tacks on a / if one doesn't exist (the theory being that it
>   has to be a directory), <Location> doesn't.
> IMHO, <Location> should behave the same, to avoid gotchas like this
> --- in other words, it should only match whole, and not partial, URL
> path segments.  The current behavior strikes me as more bug-like than
> feature-like, and I really doubt that a whole lot of people are 
> depending on it...

You'd doubt wrong. There are people out there (I know - they're the people
who keep asking for <Location> support in .htaccess) who use <Location> to
give individual files different access restrictions than the rest of the
directory. This is the only way Apache lets you do it; yes, I'd agree with
"only match whole path segments", but <Directory> tacks on a / to the end
of every "directory" it matches, which makes this impossible. For example,
we've seen at least two people from bug-reports who are doing something
along the lines of <Location /*/.htpass> - this is impossible if Apache
changes this to /*/.htpass/, as <Directory> does.

The other reason is that, unlike directories, generally <Location>-enabled
servies like status and info don't really exist on the server. So if you
had <Location /status/> and someone requested "http://.../status", they'd
get a Not Found response. I figured this not desirable behavior.

I suppose I'd be amenable to changing the behavior of Location if and only
if it really did match "path segments", not slashes. i.e. you could still
use "/some/file.txt" and not have it only match "/some/file.txt/". What's
the best way of doing this; I think thusly: if the last character of the
<Location> entry is not a "/", check to see if the first character after
the length of the entry in the URL is '/' or '\0' - if it isn't, don't
match. That'd work, right? I don't think anyone is using <Location /info>
to intentionally match /info1, /info2 and /info3. If they are, they
could just use <Location /info*> instead.

We also need (as I've said before), a <Files> (that's the Netscape Server
directive name) that matches any file, not just a directory (I agree with
the behavior of <Directory> in tacking on a / - it's called Directory,
after all). I haven't figured out the best way to make this work in
.htaccess files, though (this is a feature people have requested - and I
agree with). The simple way (ignore what's in between a <Files> that
doesn't apply) doesn't work with the htaccess cache, so it'd need to be
disabled for the rest of the request. If we cache .htaccess files longer
(as we've discussed), this could be a real performance hit.


-- Alexei Kosut <>            The Apache HTTP Server

View raw message