You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <Ia...@cnet.com> on 2001/09/13 00:48:19 UTC
another map_to_storage gotcha.
one of the guys over here stumbled over a map_to_storage gotcha/bug.
the problem is that in the default httpd.conf file the 'Options' is
in a 'Directory'. Now if the page is not served from the file system
mod_jk/mod_proxy then the 'Options' directory config is not run.
(and the default option was set to 'ALL')
the change should be something like this perhaps (haven't checked it for
validity)
or at least change the 'Options' to be in a <Location /> tag
..Ian
Index: docs/conf/httpd-std.conf
===============================================================
RCS file: /home/cvs/httpd-2.0/docs/conf/httpd-std.conf,v
retrieving revision 1.48
diff -u -r1.48 httpd-std.conf
--- docs/conf/httpd-std.conf 2001/09/06 18:27:56 1.48
+++ docs/conf/httpd-std.conf 2001/09/12 22:38:54
@@ -301,7 +301,7 @@
#
# This should be changed to whatever you set DocumentRoot to.
#
-<Directory "@@ServerRoot@@/htdocs">
+<Location "/">
#
# This may also be "None", "All", or any combination of "Indexes",
@@ -334,7 +334,7 @@
AddHandler type-map var
DirectoryIndex index.html index.html.var
-</Directory>
+</Location>
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: another map_to_storage gotcha.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 13, 2001 at 12:24:03PM -0400, Joshua Slive wrote:
> > -----Original Message-----
> > From: Ian Holsman [mailto:IanH@cnet.com]
> > What I am suggesting is to move some of these configurations to
> > <Location /> where they belong.
>
> I don't see any config directives that "belong" in <Location />.
> Please be more specific before you do anything.
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
AddHandler type-map var
DirectoryIndex index.html index.html.var
The only thing that is filesystem specific are:
Options FollowSymLinks
> > (BTW.. there are NO '<location>' directives installed in the
> > httpd-std.conf)
>
> There are commented out location directives for /server-status and
> /server-info
>
> In general, I think this is proper. Most people serve content from the
> filesystem. When serving content from the filesystem, <directory> should be
> used in preference to <location> for the reasons I mentioned a couple days
> ago in another thread. We should not be encouraging people to use
> <location> except in specific circumstances.
<Location /> is different. It is setting global configuration for the whole
server. It ensures that you don't miss some critical bits.
And your cut/dry "Directory good. Location bad." does not hold. All of my
configurations are Location based. That is because accessing the content
through one location gives you DAV capabilities, and the other location
gives your PHP- or SSI-processed content.
With Subversion, we *only* have Location directives. There is absolutely
nothing on the disk to serve.
<Location> is an important directive and needs to be used in many, many
cases.
In this particular case, the problem arose because the attempt to set
"global" options broke down. It was set only for one directory, not the
whole server URL space. Using <Location /> fixes that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: another map_to_storage gotcha.
Posted by Bill Stoddard <bi...@wstoddard.com>.
----- >
> > I keep on pointing out problems with map_to_storage because I keep on
> > running into them when I am handling reverse proxying (a major component
> > in our web design)
>
> Test cases are great :) It's good to see a module (mod_proxy) immediately reap
> the benefits of this patch. BTW - since Josh (?) isolated the optimization patch
> out of the potential ssl/php (?) problem - it might be worthwhile for a mod_proxy
> hacker to go back and reap that code for mod_proxy, as well. Dunno if it has a
> real benefit, since it doesn't have the subrequests and redirects as frequently as
> file-based modules.
>
> > > The behavior you observe is neither a bug nor a misconfiguration. Global Options
> > > should have (always) been set on <Location />. Filesystem Global Options should
> > > have (always) have been set on <Directory /> (at least since the patch for win32
> > > and relatives to allow even d:/ to be affected by Directory "/").
> >
> > the problem is that in the standard httpd-std.conf the configuration is
> > done in @@Serveroot@@/htdoc directory instead of Location "/"
> > the way the current configuration 'out of the box' would not work
> > properly for people serving pages off non-filebased systems.
> >
> > What I am suggesting is to move some of these configurations to
> > <Location /> where they belong.
>
> Agreed - as you look at the two (both Directory and Location "/") you might through
> your proposal at both this list and apache-docs for sanity review :)
+1
Bill
Re: another map_to_storage gotcha.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ian Holsman" <Ia...@cnet.com>
Sent: Wednesday, September 12, 2001 9:40 PM
> I keep on pointing out problems with map_to_storage because I keep on
> running into them when I am handling reverse proxying (a major component
> in our web design)
Test cases are great :) It's good to see a module (mod_proxy) immediately reap
the benefits of this patch. BTW - since Josh (?) isolated the optimization patch
out of the potential ssl/php (?) problem - it might be worthwhile for a mod_proxy
hacker to go back and reap that code for mod_proxy, as well. Dunno if it has a
real benefit, since it doesn't have the subrequests and redirects as frequently as
file-based modules.
> > The behavior you observe is neither a bug nor a misconfiguration. Global Options
> > should have (always) been set on <Location />. Filesystem Global Options should
> > have (always) have been set on <Directory /> (at least since the patch for win32
> > and relatives to allow even d:/ to be affected by Directory "/").
>
> the problem is that in the standard httpd-std.conf the configuration is
> done in @@Serveroot@@/htdoc directory instead of Location "/"
> the way the current configuration 'out of the box' would not work
> properly for people serving pages off non-filebased systems.
>
> What I am suggesting is to move some of these configurations to
> <Location /> where they belong.
Agreed - as you look at the two (both Directory and Location "/") you might through
your proposal at both this list and apache-docs for sanity review :)
> the code 'fix' I am proposing (if any) is to change the 'Options' to
> default to 'OPT_NONE' instead of 'OPT_ALL'. (which is what it currently
> does)
Now that I could go along with - any changes to the 'defaults' should be based
on sanity. Our .conf <Directory /> section is Options FollowSymLinks for
the filesystem. We should do no more (and perhaps not even that) for the
hardcoded default. If they want to serve files (in 2.0) let them tell us that.
It points out a tricky bit - long term - we probably (in 2.1 or 3.0) aught to
split Options into filesystem bits and non-file (or any-resource) parts. That
sure doesn't have to happen today though.
Bill
RE: another map_to_storage gotcha.
Posted by Joshua Slive <jo...@slive.ca>.
> -----Original Message-----
> From: Ian Holsman [mailto:IanH@cnet.com]
> What I am suggesting is to move some of these configurations to
> <Location /> where they belong.
I don't see any config directives that "belong" in <Location />.
Please be more specific before you do anything.
>
> (BTW.. there are NO '<location>' directives installed in the
> httpd-std.conf)
There are commented out location directives for /server-status and
/server-info
In general, I think this is proper. Most people serve content from the
filesystem. When serving content from the filesystem, <directory> should be
used in preference to <location> for the reasons I mentioned a couple days
ago in another thread. We should not be encouraging people to use
<location> except in specific circumstances.
> the code 'fix' I am proposing (if any) is to change the 'Options' to
> default to 'OPT_NONE' instead of 'OPT_ALL'. (which is what it currently
> does)
+1
In the same spirit, I would not mind changing Order to default to
allow,deny.
This would have the effect of denying access to the server unless an Allow
is used. Both these changes have the potential to break existing
configurations. But most existing configurations will not be affected
because they explictly set Order and Options.
Joshua.
Re: another map_to_storage gotcha.
Posted by dean gaudet <de...@arctic.org>.
On 12 Sep 2001, Ian Holsman wrote:
> What I am suggesting is to move some of these configurations to
> <Location /> where they belong.
+1.
-dean
Re: another map_to_storage gotcha.
Posted by Ian Holsman <Ia...@cnet.com>.
On Wed, 2001-09-12 at 19:22, William A. Rowe, Jr. wrote:
> From: "Ian Holsman" <ia...@cnet.com>
> Sent: Wednesday, September 12, 2001 6:48 PM
>
>
> > Ryan Bloom wrote:
> >
> > > On Wednesday 12 September 2001 03:48 pm, Ian Holsman wrote:
> > >
> > >>one of the guys over here stumbled over a map_to_storage gotcha/bug.
> > >>
> > >>the problem is that in the default httpd.conf file the 'Options' is
> > >>in a 'Directory'. Now if the page is not served from the file system
> > >>mod_jk/mod_proxy then the 'Options' directory config is not run.
> > >>(and the default option was set to 'ALL')
> > >>
> > >>the change should be something like this perhaps (haven't checked it for
> > >>validity)
> > >>or at least change the 'Options' to be in a <Location /> tag
> > >>
> > >
> > > Changing this in the config is the wrong solution IMHO. We need to fix the
> > > logic to not break in situations that used to work. I would prefer to fix the
> > > problem in the code, than to band-aid it and have to suffer with the user
> > > complaints later.
> >
> >
> > true. It needs to be fixed in the code as well.
> >
> > but should this stuff be on a physical location (directory) or a logical location
> > (location).
>
> Guys, forget I committed anything.
>
> If you are so narrow-focused that we aren't ready to deal with non-filesystem
> Options v.s. Root/htdocs Options, then let's revert the entire set of patches.
>
um.. no
I like the map_to_storage.
It will increase performance significantly for us, and will make our
design easier for our custom modules.
I keep on pointing out problems with map_to_storage because I keep on
running into them when I am handling reverse proxying (a major component
in our web design)
I am in no way suggesting to remove this hook.
> The behavior you observe is neither a bug nor a misconfiguration. Global Options
> should have (always) been set on <Location />. Filesystem Global Options should
> have (always) have been set on <Directory /> (at least since the patch for win32
> and relatives to allow even d:/ to be affected by Directory "/").
the problem is that in the standard httpd-std.conf the configuration is
done in @@Serveroot@@/htdoc directory instead of Location "/"
the way the current configuration 'out of the box' would not work
properly for people serving pages off non-filebased systems.
What I am suggesting is to move some of these configurations to
<Location /> where they belong.
(BTW.. there are NO '<location>' directives installed in the
httpd-std.conf)
>
> IMHO - this increases security - significantly. What on earth are the two of
> you proposing. When you speak of a 'code' fix, I'm near certain I smell a veto
> (in favor of reverting all filesystem abstraction to date) and drop all further
> efforts on dir_walk and file_walk as well.
the code 'fix' I am proposing (if any) is to change the 'Options' to
default to 'OPT_NONE' instead of 'OPT_ALL'. (which is what it currently
does)
>
> Bill
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: another map_to_storage gotcha.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ian Holsman" <ia...@cnet.com>
Sent: Wednesday, September 12, 2001 6:48 PM
> Ryan Bloom wrote:
>
> > On Wednesday 12 September 2001 03:48 pm, Ian Holsman wrote:
> >
> >>one of the guys over here stumbled over a map_to_storage gotcha/bug.
> >>
> >>the problem is that in the default httpd.conf file the 'Options' is
> >>in a 'Directory'. Now if the page is not served from the file system
> >>mod_jk/mod_proxy then the 'Options' directory config is not run.
> >>(and the default option was set to 'ALL')
> >>
> >>the change should be something like this perhaps (haven't checked it for
> >>validity)
> >>or at least change the 'Options' to be in a <Location /> tag
> >>
> >
> > Changing this in the config is the wrong solution IMHO. We need to fix the
> > logic to not break in situations that used to work. I would prefer to fix the
> > problem in the code, than to band-aid it and have to suffer with the user
> > complaints later.
>
>
> true. It needs to be fixed in the code as well.
>
> but should this stuff be on a physical location (directory) or a logical location
> (location).
Guys, forget I committed anything.
If you are so narrow-focused that we aren't ready to deal with non-filesystem
Options v.s. Root/htdocs Options, then let's revert the entire set of patches.
The behavior you observe is neither a bug nor a misconfiguration. Global Options
should have (always) been set on <Location />. Filesystem Global Options should
have (always) have been set on <Directory /> (at least since the patch for win32
and relatives to allow even d:/ to be affected by Directory "/").
IMHO - this increases security - significantly. What on earth are the two of
you proposing. When you speak of a 'code' fix, I'm near certain I smell a veto
(in favor of reverting all filesystem abstraction to date) and drop all further
efforts on dir_walk and file_walk as well.
Bill
Re: another map_to_storage gotcha.
Posted by Ian Holsman <Ia...@cnet.com>.
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" <rb...@covalent.net>
> 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." <wr...@rowe-clan.net>
> > > Sent: Wednesday, September 12, 2001 9:22 PM
> > >
> > > > From: "Ryan Bloom" <rb...@covalent.net>
> > > > 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
Re: another map_to_storage gotcha.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
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." <wr...@rowe-clan.net>
> > Sent: Wednesday, September 12, 2001 9:22 PM
> >
> > > From: "Ryan Bloom" <rb...@covalent.net>
> > > 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
Re: another map_to_storage gotcha.
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 12 September 2001 07:26 pm, William A. Rowe, Jr. wrote:
> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> Sent: Wednesday, September 12, 2001 9:22 PM
>
> > From: "Ryan Bloom" <rb...@covalent.net>
> > 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.
> >
> > You are out of your mind
>
> [sorry, wrong alt key]
>
> ... if you confuse <Location /> (the root of the web server's URI space)
> with <Directory /> (the root of the filesystem.)
>
> 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.
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.
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.
And please don't tell me I am out of my mind. :-)
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: another map_to_storage gotcha.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Wednesday, September 12, 2001 9:22 PM
> From: "Ryan Bloom" <rb...@covalent.net>
> 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.
>
> You are out of your mind
[sorry, wrong alt key]
... if you confuse <Location /> (the root of the web server's URI space) with
<Directory /> (the root of the filesystem.)
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?
Re: another map_to_storage gotcha.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
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.
You are out of your mind
Re: another map_to_storage gotcha.
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 12 September 2001 04:48 pm, Ian Holsman wrote:
> Ryan Bloom wrote:
> > On Wednesday 12 September 2001 03:48 pm, Ian Holsman wrote:
> >>one of the guys over here stumbled over a map_to_storage gotcha/bug.
> >>
> >>the problem is that in the default httpd.conf file the 'Options' is
> >>in a 'Directory'. Now if the page is not served from the file system
> >>mod_jk/mod_proxy then the 'Options' directory config is not run.
> >>(and the default option was set to 'ALL')
> >>
> >>the change should be something like this perhaps (haven't checked it for
> >>validity)
> >>or at least change the 'Options' to be in a <Location /> tag
> >
> > Changing this in the config is the wrong solution IMHO. We need to fix
> > the logic to not break in situations that used to work. I would prefer
> > to fix the problem in the code, than to band-aid it and have to suffer
> > with the user complaints later.
>
> true. It needs to be fixed in the code as well.
>
> but should this stuff be on a physical location (directory) or a logical
> location (location).
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.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: another map_to_storage gotcha.
Posted by Ian Holsman <ia...@cnet.com>.
Ryan Bloom wrote:
> On Wednesday 12 September 2001 03:48 pm, Ian Holsman wrote:
>
>>one of the guys over here stumbled over a map_to_storage gotcha/bug.
>>
>>the problem is that in the default httpd.conf file the 'Options' is
>>in a 'Directory'. Now if the page is not served from the file system
>>mod_jk/mod_proxy then the 'Options' directory config is not run.
>>(and the default option was set to 'ALL')
>>
>>the change should be something like this perhaps (haven't checked it for
>>validity)
>>or at least change the 'Options' to be in a <Location /> tag
>>
>
> Changing this in the config is the wrong solution IMHO. We need to fix the
> logic to not break in situations that used to work. I would prefer to fix the
> problem in the code, than to band-aid it and have to suffer with the user
> complaints later.
true. It needs to be fixed in the code as well.
but should this stuff be on a physical location (directory) or a logical location
(location).
>
> Ryan
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>
Re: another map_to_storage gotcha.
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 12 September 2001 03:48 pm, Ian Holsman wrote:
> one of the guys over here stumbled over a map_to_storage gotcha/bug.
>
> the problem is that in the default httpd.conf file the 'Options' is
> in a 'Directory'. Now if the page is not served from the file system
> mod_jk/mod_proxy then the 'Options' directory config is not run.
> (and the default option was set to 'ALL')
>
> the change should be something like this perhaps (haven't checked it for
> validity)
> or at least change the 'Options' to be in a <Location /> tag
Changing this in the config is the wrong solution IMHO. We need to fix the
logic to not break in situations that used to work. I would prefer to fix the
problem in the code, than to band-aid it and have to suffer with the user
complaints later.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------