httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/server core.c request.c
Date Mon, 27 Aug 2001 14:47:28 GMT
From: "Barrie Slaymaker" <barries@slaysys.com>
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" <barries@slaysys.com>
> > Sent: Monday, August 27, 2001 3:22 AM
> > 
> > 
> > > On Sun, Aug 26, 2001 at 05:10:17AM -0000, wrowe@apache.org 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.
> 


Mime
View raw message