Re: FileSystem v.s. Other Resources [was configurable Location?]

[Greg Marr <gr...@alum.wpi.edu>]

At 10:22 AM 2/5/2004, gregames@apache.org wrote:
>Thanks for the feedback, Will.
>
>William A. Rowe, Jr. wrote:
>>At 03:39 PM 2/4/2004, gregames@apache.org wrote:
>>
>>>But then if I play devil's advocate, someone could see the new directive 
>>>and turn it on when it's not appropriate and cause Bad Things to 
>>>happen.  Mainly I'm looking for comments on whether this should be 
>>>configurable or not.
>>
>>Yes, I'm one who will agree with your devil's position :)  I know the problem
>>you are trying to solve, and changing the behavior of <Directory > isn't 
>>quite the solution...
>
>I'm only changing <Location > ... <Directory > is unaffected.

Well, that's not entirely true.  The <Directory> is affected indirectly, 
because it no longer applies.  The behavior currently is: it applies to 
everything it matches.  This would change it to: it applies to everything 
it matches unless it also matches a <Location>, in which case it doesn't apply.

Re: FileSystem v.s. Other Resources [was configurable Location?]

[Greg Ames <gr...@apache.org>]

Greg Marr wrote:

>> I'm only changing <Location > ... <Directory > is unaffected.
> 
> 
> Well, that's not entirely true.  The <Directory> is affected indirectly, 
> because it no longer applies.  The behavior currently is: it applies to 
> everything it matches.  This would change it to: it applies to 
> everything it matches unless it also matches a <Location>, in which case 
> it doesn't apply.

OK, got it.  Thanks for the clear explanation.

This could possibly be handled by checking for overlaps between <Location > and 
<Directory > at config time, especially if they are sorted in least-to-most 
specific order as wrowe suggests.

But my current favorite idea is Joshua's suggestion for the module to declare 
that the content is virtual, pure and simple.  In that case, any such overlaps 
are an admin screwup IMO.  GET /server-status/index.html doesn't make any sense 
to me even if such a directory exists.

Greg

Re: FileSystem v.s. Other Resources [was configurable Location?]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 10:43 AM 2/5/2004, Greg Marr wrote:
>At 10:22 AM 2/5/2004, gregames@apache.org wrote:
>>Thanks for the feedback, Will.
>>
>>William A. Rowe, Jr. wrote:
>>>At 03:39 PM 2/4/2004, gregames@apache.org wrote:
>>>
>>>>But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen.  Mainly I'm looking for comments on whether this should be configurable or not.
>>>
>>>Yes, I'm one who will agree with your devil's position :)  I know the problem
>>>you are trying to solve, and changing the behavior of <Directory > isn't quite the solution...
>>
>>I'm only changing <Location > ... <Directory > is unaffected.
>
>Well, that's not entirely true.  The <Directory> is affected indirectly, because it no longer applies.  The behavior currently is: it applies to everything it matches.  This would change it to: it applies to everything it matches unless it also matches a <Location>, in which case it doesn't apply.

Right - I understand.

I'm saying (as you pointed out) that it's too dangerous :)  Defies the principle
of least surprise.  They configure <Dir > blocks only to have them ignored.

The only safe way to do what you are suggesting, is to yank the default file
handler from under the request anytime the user has overridden the <Dir >
checks.  Simplest way to do that is bind them together as a filesystem
module.

Oh, the same problems (of yanking <Dir > out from under the user) would be
true of the CGI handler, as well as third party modules that do things with
the filesystem.  It would be important that they could explicitly enable the
module to add <Dir > handling.

Which brings us back to square one.  I'd actually argued a long time ago
that a module that handles requests outside of the filesystem should be
responsible for bypassing the <Dir > handler itself.  For example, mod_proxy
satisfies the map_to_storage hook on it's own, therefore never hitting <Dir >.

Bill