Here is something similar to what tripped us up:
#The following is std install
<Directory />
Options FollowSymLinks
</Directory>
<Directory htdocs>
Options FollowSymLinks Indexes ExecCGI Multiviews
</Directory>
#
#our module does something similiar to this
#
<Location />
ProxyPass http://www.foo.com/
SetOutputFilter INCLUDES
</Location>
now.. in this case the INCLUDES filter SHOULD NOT RUN.
as we do not have options 'includes' turned on anywhere
the problem is that the includes filter DOES RUN.
if we change the <Directory htdocs> to <Location />
then it does what it is supposed to.
On Wed, 2001-09-12 at 20:00, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2001 9:43 PM
>
>
> > On Wednesday 12 September 2001 07:26 pm, William A. Rowe, Jr. wrote:
> > > From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> > > Sent: Wednesday, September 12, 2001 9:22 PM
> > >
> > > > From: "Ryan Bloom" <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, September 12, 2001 7:02 PM
> > > >
> > > > > Both. Directories and locations are equivalent. The only difference
> > > > > between the two containers, is that one maps to a location on the file
> > > > > system, and the other doesn't.
> > > >
> > > They are cousins, but they do entirely different things. This has always
> > > been so.
> > >
> > > Try in 1.3...
> > >
> > > DocumentRoot /www/pages
> > > <Directory /www/pages>
> > > order allow,deny
> > > allow from all
> > > </Directory>
> > > <Location />
> > > order deny,allow
> > > deny from all
> > > </Location>
> > >
> > > What do you observe?
> >
> > Read it again Will. I did NOT say that
> > <Directory /> is equivalent to <Location />
> >
> > I said that <Directory> and <Location> are equivalent operations.
>
> They are not equivilant.
>
> Try the converse...
> DocumentRoot /www/pages
> <Directory /www/pages>
> order deny,allow
> deny from all
> </Directory>
> <Location />
> order allow,deny
> allow from all
> </Location>
>
> Location has higher precidence. Directory has absolute mapping to the file system
> (significant on case-insensitive filesystems, esp with funny little aliases about.)
>
> > When I set the DocumentRoot to /usr/local/apache/htdocs, then every
> > URI that does not map to the disk can effectively be treated as residing
> > under /usr/local/apache/htdocs.
>
> Yes, that is correct, until you break the mapping with Alias directives.
>
> At that point, a user can simply Alias /extra-bin/ /usr/local/bin/.
>
> You cannot use Location as a 'substitute' for Directory without creating
> significant potential misconfigurations.
>
> > This way, I can set Options at root of the filesystem, and it still applies
> > for all the URIs. If I do the following:
> >
> > DocumentRoot /usr/local/apache/htdocs
> > <directory /usr/local/apache/htdocs>
> > Options ALL
> > </directory>
> >
> > That should be equivalent to
> >
> > <Location />
> > Options ALL
> > </Location>
> >
> > by doing the DocumentRoot, I have set up a relationship between the URI /
> > and the directory /usr/local/apache/htdocs. I am just asking that the relationship
> > be honored.
>
> The relationship is more like
>
> configresult = (Location (URI ~= Directory (URI ~= File (URI ~= Location)))
>
> where .htaccess is a subset of the Directory.
>
> If we add <Location /> Allow Everything </Location> the entire filename space is
>blown
> wide open. This is part of the reason for my suggesting a LocationFileRoot sort of
> directive within Location. You actually end up controlling both halves of the coin
> in one shot.
>
> > And please don't tell me I am out of my mind. :-)
>
> Appologies, your mind is most definately there within you. I'm having trouble
>reading
> where it is leading in this discussion. Without any examples (as I've suggested that
> Ian post) it's hard to say where anyone is going. Some changes (within the code)
>would
> be good to eliminate unsafe assumptions (defaults.) I read your post as relaxing the
> config, which I definately disagree with.
>
> Bill
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
