On Mon, 7 Jan 2002, William A. Rowe, Jr. wrote: > From: "Ryan Bloom" <[EMAIL PROTECTED]> > > I would like to discuss the reasoning behind this change. Why are we trying > > to overload the meaning of DocumentRoot this way? > Because it allows the DocumentRoot to be, well, nonexistant.
This is very useful in environments where you want an URI space that doesn't necessarily line up with anything on a file system. This would be very useful for things such as mod_perl, XML/XSLT solutions, RTSP/Icecast servers, etc. > It allows us to have the following section; > <Location /nowhere> > DocumentRoot unset > </Location> > that makes it 100% clear where nowhere goes. It is also possibly easier > than alias, since I am not sure if I like the "unset" keyword. In the mime and handler case we use Add/Remove and we use "On" and "Off" already. Maybe using "Off" is valid here? Then we could probably also use "On" to enable the DocumentRoot again, where it would enable it to a previously set DocumentRoot higher up in the tree or default to the compiled in default if there was nothing defined elsewhere. > works the same as > Alias /private /some/private/resource > <Location /private> > Options deny,allow > Allow from only.me > </Location> (I assume here you meant "Order" instead of "Options") You could also potentially consider writing this as <Directory /some/private/resource> Alias /private # Or maybe Uri /private Options deny,allow Allow from only.me </Directory> This does not change the notion of having a single DocumentRoot and allows for the same flexibility (if we remove the requirement for a DocumentRoot and allow for DocumentRoot [Off|unset|path] or whatever). Cheers, -- Sander van Zoest [EMAIL PROTECTED] High Geek http://Sander.vanZoest.com/
