From: "Barrie Slaymaker" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:22 AM
> 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).
OUTCH! It does, thank you!
if ((core_a->r != NULL) < (core_b->r != NULL)) {
return -1;
}
else if ((core_a->r != NULL) > (core_b->r != NULL)) {
return 1;
}
does that look better :-? I'll commit as soon as someone tells me sanity (or at least
my abuse of pointers as bools) is cured :)
Bill
> > 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.
>