On 12/12/2016 01:23 PM, Yann Ylavic wrote:
On Mon, Dec 12, 2016 at 10:07 PM, Jacob Champion <champio...@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.
