At 10:43 AM 2/5/2004, Greg Marr wrote: >At 10:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: >>Thanks for the feedback, Will. >> >>William A. Rowe, Jr. wrote: >>>At 03:39 PM 2/4/2004, [EMAIL PROTECTED] 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
