From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Monday, January 07, 2002 12:36 PM
> On Monday 07 January 2002 05:14 am, William A. Rowe, Jr. wrote: > > <Location server-status> > > SetHandler Status > > DocumentRoot unset > > </Location> > > > > gets rid of the stats that FirstBill complained of [which were in 1.3 as well.] > > I was under the impression that those stats could be removed by having the > status module implement a map-to-storage function. Did I misunderstand the > purpose of that hook? I realize that putting the DocumentRoot directive in the > core would allow a module author to not have to implement the map-to-storage > hook and still receive the same benefit. I do not consider that a good reason > to introduce the complexity of allowing DocumentRoot inside a <Location> > container. IFF the module author writes a map to storage hook, and if the handler is determined in the translate-name hook, then yes, any module can subvert the dir/file walks. But if we look at very simple modules, unsetting the document root gives us the same control, without writing a map-to-storage hook fn. Note that mod_alias'es are always processed sequentially. Locations are parsed by segments, if I'm not mistaken. Today; alias /foo -> /www/thesefiles alias /foo/bar -> /www/thosefiles given im that order mean that all /foo requests are redirected to /www/thesefiles, and /www/thosefiles are never hit. Location parsing makes more sense, so a DocumentRoot directive in <location /foo/bar> will always supersceed the DocRoot of <location /foo> if a request for /foo/bar/bleh comes in. This, I believe, is goodness. One last observation; mod_alias is an add-in module. DocumentRoot would be a core (or someday, a filesystem module) directive. When we implode the core's dependence on the filesystem as a document store, DocumentRoot will make more sense than 'aliasing' ourselves to death :)
