httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: FileSystem v.s. Other Resources [was configurable Location?]
Date Mon, 09 Feb 2004 21:04:35 GMT
At 02:11 PM 2/9/2004, wrote:
>William A. Rowe, Jr. wrote:
>>At 04:34 PM 2/6/2004, 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

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.


View raw message