At 02:11 PM 2/9/2004, [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
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.
right. From merge_core_dir_configs():
if (new->handler) {
conf->handler = new->handler;
}...so currently it only lives in config land until the fixups phase if I'm reading the code correctly. That's the problem.
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.
sounds good
Even if it's overridden in a <Directory > block, the <Location > block it points at would still override it. So this change seems harmless.
I'll buy it
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.
Maybe you're right.
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.
The performance of mod_info and mod_status doesn't bother me. Seeing the system calls they generate in a trace does, but I'll get over it. Isn't mod_dav virtual content though from the core's point of view (pls excuse my ignorance)? mod_proxy is, but it already has working special case code scattered throughout the core. (hmmm, might be some hints as to where the hits are for a more general solution)
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.
Amen
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.
right
Greg
