On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
> From: "Barrie Slaymaker" <[EMAIL PROTECTED]>
> Sent: Monday, August 27, 2001 3:22 AM
>
>
> > On Sun, Aug 26, 2001 at 05:10:17AM -0000, [EMAIL PROTECTED] wrote:
> > > core_a = ap_get_module_config(a->elt, &core_module);
> > > core_b = ap_get_module_config(b->elt, &core_module);
> > > - if (IS_SPECIAL(core_a)) {
> > > - if (!IS_SPECIAL(core_b)) {
> > > - return 1;
> > > - }
> > > +
> > > + if (core_a->r < core_b->r) {
> > > + return -1;
> > > }
> > > - else if (IS_SPECIAL(core_b)) {
> > > - return -1;
> > > + else if (core_a->r > core_b->r) {
> > > + return 1;
> > > }
> >
> > Does this bit mean that regex-based sections won't run in config-file
> > order, but in order of their positions in the heap?
>
> They always have run in this order,
>
> 1. Non regex expressions first, then all regex'es
> 2. By the number of components (so '/', then '/foo', then '/foo/bar')
> 3. By their order in the configuration file.
#3 is why I responded. This patch seems to change that nice behavior;
like regexes are sorted by their addresses (the value of core_{a,b}->r)
rather than their position (core_{a,b}->orig_index).
> The only thing this patch changes is that 'specials' (such as proxy: entries)
> cannot be in <Directory > sections. The proxy: entries can now be configured
> with <Proxy > sections. And my patch to run Proxy entries doesn't sort them
> at all (I have posted the question to the modproxy-dev list, if we even want
> them sorted by any critera.)
Yup, I like the <Proxy section stuff a lot.
As far as sorting, it would be nice for everyone's sanity if
<(Directory|Location|Proxy)(Match)? sections were sorted using as
similar a logic as possible. Given the number of incremental directives
that are starting to crop up, sort order is going to be very important
to config stability. By incremental directives, I mean directives where
previous settings are modified by directives occuring in later directory
sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
and like external modules do (see AxKit's directives for a lot of
these).
Just the ramblings of someone who's had to explain the current state of
affairs and watch the heads shaking...
- Barrie
P.S. I also like the suggestion that went by to make the first
ap_location_walk "stick" and do away with the second. It's much more
intuitive to me: URIs get run through the <Location mill first, then
(<Directory and <Files) or (<Proxy) section. Seems like the need for
the duplicate ap_location_walk()s should be much less now that <PRosy
sections exist.
