httpd-dev mailing list archives

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


> 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