httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Are Location directives broken (or why run directory_walk if location_walk finds a handler?)
Date Mon, 09 Apr 2001 06:21:19 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:

    Apache would keep a tree which corresponds to the URL space. 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.

    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.

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.


Greg Stein,

View raw message