httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Are Location directives broken (or why run directory_walk if location_walk finds a handler?)
Date Wed, 11 Apr 2001 21:51:59 GMT

> On Sat, Apr 07, 2001 at 08:54:51PM -0500, William A. Rowe, Jr. wrote:
> >...
> > For 2.1 (or 3.0) this nonsense must change.  If I say <Location /> SetHandler
SQLSpace-handler
> > then the entire file-system part of httpd needs to just _disappear_.
>
> You got that right. After doing the stuff for mod_dav's arbitrary backends,
> I've been thinking on the right form for Apache for quite a while. Rather
> than respond to the items in your post, I'll briefly explain how I believe
> we should be doing the processing:
>

I don't grok this explanation...

>     Apache would keep a tree which corresponds to the URL space.

When is this tree built? At server start or dynamically? Based on what directives? Location?
Alias?
Rewrite rules?  A simple first approach (and perhaps the only approach) is to define the URL
space
as being -defined- by Location directives.

> The root of
>     the tree corresponds to "/" on the virtual server. Children of each node
>     are a hash table, keyed by the URI component. Nodes only exist where
>     configuration has occurred -- the node configuration typically means
>     children exist, but they simply aren't part of the URL-space tree.
>

Please give a simple example :-)

>     One of the config options at a node is a directory/file path (the Alias
>     directive). Alternatively, the node could point to a database of
>     content, or to a custom module, or whatever. The basic point is that
>     each node says "<this> function/module/handler specifies the URL space
>     for my children (which are not explicitly listed in the node's
>     children)." (note: it only translates URLs into an internal resource
>     identifier; the handler for a resource is still separate)
>
>     Thus, if we see /foo, the system looks at the tree, finds "/" and that
>     it is mapped to DIR in the filesystem. However, we also see "foo" as a
>     child, so we go to that node. That node points to a custom module for
>     that space. If we see "/bar", then we do a directory walk to bar.
>
>     I believe that we'd want to look for a .htaccess in "/" since that *is*
>     the parent resource of /foo, even though /foo is handled special (it may
>     want to establish security policy for everything in "/"). Of course, the
>     config for "/" could disable .htaccess files.
>
>     etc.
>
> Having the tree in memory means that we can quickly map a URL to a resource.
> Currently, we have linear lists of directories, locations, and files that we
> need to scan. The tree is also much nicer from an introspection point -- we
> can navigate it to discover what the URL space looks like. This is actually
> a HUGE bonus for DAV's PROPFIND method. At the moment, I return results for
> a PROPFIND based on what I see in the filesystem (imagine PROPFIND to be an
> "ls" for the web server). If somebody has attached some kind of URL space in
> there, the PROPFIND doesn't return it. However, with the tree, I can see
> those children and return results for them.
>
> The trees would be per-server, and (sub)trees could be shared.
>
> But whatever... this is a big restructuring best left post-2.0.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>


Mime
View raw message