On Tue, Dec 13, 2016 at 12:00 AM, Jacob Champion <champio...@gmail.com> wrote:
> 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.
Oh, right, I thought internal-requests were like sub-requests, with
rr->pool being a subpool of r->pool, but that's not the case as you
mention.
So I guess r1773861 is OK already, though the below may be simpler/cleaner now:
Index: modules/http/http_filters.c
===================================================================
--- modules/http/http_filters.c (revision 1773865)
+++ modules/http/http_filters.c (working copy)
@@ -689,13 +689,10 @@ static APR_INLINE int check_headers(request_rec *r
static int check_headers_recursion(request_rec *r)
{
- request_rec *rr;
- for (rr = r; rr; rr = rr->prev) {
- void *dying = NULL;
- apr_pool_userdata_get(&dying, "check_headers_recursion", rr->pool);
- if (dying) {
- return 1;
- }
+ void *dying = NULL;
+ apr_pool_userdata_get(&dying, "check_headers_recursion", rr->pool);
+ if (dying) {
+ return 1;
}
apr_pool_userdata_setn("true", "check_headers_recursion", NULL, r->pool);
return 0;
_
