httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: svn commit: r1773865 - /httpd/httpd/trunk/modules/http/http_filters.c
Date Mon, 12 Dec 2016 23:00:49 GMT
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.

Can you send me a config snippet that reproduces the loop with 
ErrorDocument? I'm not arguing against your followup patches; I just 
want to make sure a correct test case gets into the suite. :D

> In r1773861, the recursion wouldn't work with "ErrorDocument
> /some/file" for example, because ap_die() may either call
> ap_intern_redirects() which is caught by ap_is_initial_req(), or
> ap_send_error_response() directly which is caught by pool userdata
> "dying".
>
> r1773865 allows to not depend on ap_die() internals, and also allows
> to try ap_die() (once) for internal redirects that
> ap_http_header_filter() did not generated itself...
>
> Regards,
> Yann.
>


Mime
View raw message