You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Gearls <ni...@gmail.com> on 2017/10/17 13:59:22 UTC

Potential output filter order of processing

Hello,

I encounter a problem with the order of processing of output filters.
Maybe I'm missing some background but there's something very weird.
I'll show the example with mod_substitute but I imagine it's similar for 
other modules (although I'm not sure).

Case 1:
    Subst "s/x/1x/qn"
    Subst "s/x/2x/qn"
    Result: 'x' is replaced by '12x' (seems logical)

Case 2:
    <Location />
    Subst "s/x/1x/qn"
    Subst "s/x/2x/qn"
    </Location>
    Result: 'x' is replaced by '12x' (seems logical)

Case 3:
    <Location />
    Subst "s/x/1x/qn"
    </Location>
    <Location />
    Subst "s/x/2x/qn"
    </Location>
    Result: 'x' is replaced by '21x' ?!?

Apache is supposed to execute location from top to bottom, no? So why 
does it parse them the other way around in this case?
The filter is defined as AP_FTYPE_RESOURCE; does this impact the order 
of processing locations?

Thanks for any hint

Re: Potential output filter order of processing

Posted by Eric Covener <co...@gmail.com>.
On Tue, Oct 17, 2017 at 9:59 AM, Nick Gearls <ni...@gmail.com> wrote:
> Hello,
>
> I encounter a problem with the order of processing of output filters.
> Maybe I'm missing some background but there's something very weird.
> I'll show the example with mod_substitute but I imagine it's similar for
> other modules (although I'm not sure).
>
> Case 1:
>    Subst "s/x/1x/qn"
>    Subst "s/x/2x/qn"
>    Result: 'x' is replaced by '12x' (seems logical)
>
> Case 2:
>    <Location />
>    Subst "s/x/1x/qn"
>    Subst "s/x/2x/qn"
>    </Location>
>    Result: 'x' is replaced by '12x' (seems logical)
>
> Case 3:
>    <Location />
>    Subst "s/x/1x/qn"
>    </Location>
>    <Location />
>    Subst "s/x/2x/qn"
>    </Location>
>    Result: 'x' is replaced by '21x' ?!?
>
> Apache is supposed to execute location from top to bottom, no? So why does
> it parse them the other way around in this case?
> The filter is defined as AP_FTYPE_RESOURCE; does this impact the order of
> processing locations?

Each module merges the config pairwise at config time, creating its
own data structures.
So if it's the wrong order, this would be in mod_substitute per_dir
config merge function.