httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barrie Slaymaker <barr...@slaysys.com>
Subject Re: cvs commit: httpd-2.0/server core.c request.c
Date Mon, 27 Aug 2001 13:22:13 GMT
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).

> 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