httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: another map_to_storage gotcha.
Date Thu, 13 Sep 2001 02:47:53 GMT
From: "Ian Holsman" <>
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
> > have (always) have been set on <Directory /> (at least since the patch for
> > 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.


View raw message