At 02:11 PM 2/9/2004, [EMAIL PROTECTED] wrote: >William A. Rowe, Jr. wrote: >>At 04:34 PM 2/6/2004, [EMAIL PROTECTED] wrote: >> >>>Joshua Slive wrote: > >>>>And perhaps I'm going way off in left field here, but why should this be >>>>user-configurable at all? Shouldn't the (for example) server-status >>>>handler know itself that it is a virtual handler, and therefore indicate >>>>that the directory-walk should be skipped? >>> >>>I like it! assuming we tweak it to be the module's responsibility to declare this >>>property, vs. strictly the handler's (too late) >>Modules can do that today with some very trivial code... > >I think I see a problem. No doubt it could be made to work with a simple tweak. > >SetHandler in the location container sets the handler field in the core "dir" conf >during location walk.
??? I'm not seeing that, the dir/location walk doesn't set up r->handler at all. You can use the SetHandler directive in location or dir contexts. I suppose if it is set in a location, we set r->handler it in the translate_name phase. Even if it's overridden in a <Directory > block, the <Location > block it points at would still override it. So this change seems harmless. >map_to_storage runs, but r->handler hasn't been updated due to the SetHandler yet. >virtual_map_location doesn't know that it owns this URI. > >An unnecessary directory walk happens. Yes - the module needs to determine ownership in the translate_name phase. >core_override_type runs during the fixups phase and sets r->handler to the handler >specified in the <Location > block from the handler field in the core "dir" config. >It's too late to affect the directory walk. > >Another nit is that every module with virtual content would repeat essentially the >same code, other than checking the unique handler name of course, and add to mainline >path length on every request by increasing the number of map_to_storage routines. We >would depend on each module zapping r->filename. This doesn't bother me for 2.0 if >we can save a directory walk. I guess I'm really concerned, after some of the problems and confusion this thread has revealed, about changing the behavior at all in 2.0. If we can get our own core "not a file" handlers to behave nicely (by fixing r->handler back in the translate_name phase) I would feel better about a minor change. That's a pretty restrictive change that would only affect, mod_info, mod_status etc. Other authors could do likewise if they understand the ramifications. But it seems after reading all of the comments, we aught to make some appropriate design changes in 2.2 so this entire solution is robust without breaking existing modules and possibly introducing security issues. After all, Apache 2.0 should be stable, and we should spend some time breaking the server in 2.1-dev with the eye to releasing a faster, more optimized 2.2. And yup - *every* handler author aught to make the appropriate change, because only they understand what's up with their content, and if it should be walked by dir and file sections, or not. We know mod_info and mod_status don't need to be, so we can code that ourselves. Bill
