From: "Brian Pane" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 10:37 PM
> I think you and I might be talking about different trees. Are you
> thinking of pre-scanning for htaccess files in selected dirs in the
> document root? The tree that I'm walking through in the patch is a
> virtual one formed by finding prefix-match relationships among the
> <Directory> pathnames. E.g., if there are <Directory> blocks in
> httpd.conf for /foo, /bar, /foo/bar, and /*/icons, then the pre-merge
> algorithm creates 5 cached configs:
> server_default+/foo
> server_default+/bar
> server_default+/foo+/foo/bar
> server_default+/foo+/*/icons
> server_default+/bar+/*/icons
> If we get a request for /foo/bar/etc/index.html, and there's an htaccess
> file under /foo/bar/etc, then the code takes the pre-merged config for
> server_default+/foo+/foo/bar, loads the htaccess file, and overlays the
> config from the htaccess file on top of the pre-merged config to get the
> configuration that it uses for the request. (So directory_walk ends up
> doing one dir-merge, instead of the three that it would do in this example
> without caching.) Are you thinking of a more general solution where we
> statically cache selected htaccess files too?
We are on the same page :) FWIW, I've made a few comments around your patch,
and am reviewing it in more detail. I'll have my comments by the end of the
week (I'm all over creation this week trying to get things done.)
I'm not planning to allow the admin to statically cache anything other than
the preloaded .conf parsing. Heck, if they wanted it, they would have included
it in the conf or included subfiles into their conf, no?
Perhaps, though, an advanced flavor of Include conffile would offer the admin
the opportunity to restrict the config allowed from that conffile (as they
can do with htaccess files) so they could incorporate vhost user's configs as
part of startup, instead of per-request. I think that might be pretty slick :)
Of course we can't not start if there is a config error, we have to dump that
file and keep rolling on with the startup.
BTW - I intend to finish optimizing the second directory_walk implementation
and orphan the first within a matter of a two weeks. So you might want to
also see how it applies therein. One trick; I plan to leverage as much
canonical information I can get, so pre-tested <Directory > sections are a
real blessing to that code. Can't promise a _one_ stat request (in all
cases) but it will be better than the current /a/a/a/a... fooness that can
results from walking the get_path_info() code back asswards.
When we start skipping things we _trust_ are directories, and land with an
APR_ENOTDIR, we know we can't trust the result anyways (the admin _told_ us
it would be a directory, no?!?) and can dump them with a 404 or something.
Bill
