internal redirect and module context

Dk Jack dnj0496 at gmail.com
Sat Jan 22 00:07:26 UTC 2022


Hi,
I have a question related to internal redirect, I am hoping someone from
this forum can clarify. The email is a bit long since I wanted to provide
enough background for my situation.

In my module, I am creating my module context and saving some state. Some
of this state is allocated using ngx_palloc. I am releasing this memory by
adding a pool clean up handler.

In my module, for certain requests I am doing an internal redirect. My code
for redirect looks something like this:

    ngx_http_internal_redirect(r, &new_uri, &r->args);
    ngx_http_finalize_request(r, NGX_DONE);

According to the documentation
http://nginx.org/en/docs/dev/development_guide.html#http_request_redirection

it says, on calling internal_redirect, the module context will be erased to
avoid inconsistencies. It also says, the processing returns to the
NGX_HTTP_SERVER_REWRITE_PHASE. To understand the behavior better, I
attached a debugger and added a breakpoint after the above two lines. When
the debugger stopped at my breakpoint, my module context still seems to be
valid. I added a second breakpoint in my rewrite-handler and allowed the
debugger to continue. Now when the debugger stopped at the second
breakpoint, my module context was erased which seems consistent with the
documentation.

So my question is, if my context is erased, what happens to the memory I
allocated before my module invoked the internal redirect call? I put a log
statement in my cleanup function and I observed that it is getting invoked
only once at the end of the request processing. It is not getting called
when my context is erased after an internal redirect. Since I need my
context data after redirection, do I reallocate and recreate it? Since my
clean up code is getting called only once. Would this lead to a memory leak
if I reallocated after the internal redirect call because I'd be allocated
once before redirect and once after redirect. Any help or clarification in
this regard is greatly appreciated.

Dk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20220121/6f4dcf48/attachment.htm>


More information about the nginx-devel mailing list