httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject AW: svn commit: r1773865 - /httpd/httpd/trunk/modules/http/http_filters.c
Date Tue, 13 Dec 2016 09:48:24 GMT


> -----Ursprüngliche Nachricht-----
> Von: Jacob Champion [mailto:champion.p@gmail.com]
> Gesendet: Dienstag, 13. Dezember 2016 00:01
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1773865 -
> /httpd/httpd/trunk/modules/http/http_filters.c
> 
> On 12/12/2016 01:23 PM, Yann Ylavic wrote:
> > On Mon, Dec 12, 2016 at 10:07 PM, Jacob Champion
> <champion.p@gmail.com> wrote:
> >
> >>
> >> What's the case where this catches recursion that the previous logic
> in
> >> r1773861 did not handle? I'm trying to write a test that fails on
> r1773861
> >> and succeeds on r1773865, but I haven't figured it out yet.
> >
> > I think it's more r1773862 that fixes your test case.
> 
> To clarify: I can't reproduce any problems with r1773861 in the first
> place, even with ErrorDocument. I agree that r1773862 (and r1773865)
> work for me; I just don't know what makes them functionally different.
> In my attempted test cases, I can't find any case where the rr->pool
> used during the internal redirect differs from the original r->pool.

I don't see any case where this is needed. Internal redirects always use the same pool as
the original request.
So it should be sufficient to memorize just in r->pool.

Another aspect of all these patches that I don't get is why we need to eat the contents of
the
original brigade? IMHO we don't need to do this. It is thrown away automatically at the end
of the request
and as we leave with an AP_FILTER_ERROR after the ap_die it should never be sent. If we want
to play safe
we can remove ourselves from the filterchain after returning from ap_die.
This could make the whole stuff much less complex.

Regards

Rüdiger
Mime
View raw message