internal redirect and module context

[Dk Jack]

That is exactly what I needed. Thank you.

Dk.

On Sat, Jan 22, 2022 at 11:08 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sat, Jan 22, 2022 at 02:19:05AM -0800, Dk Jack wrote:
>
> > Maxim,
> > Thanks for responding to my query. I am passing the original context
> > pointer to the clean up handler. When my cleanup handler is called I am
> > retrieving the context pointer to clean up external resources. Based on
> > your response, the pointer saved in the cleanup handler should still be
> > valid and should be still safe to use and no memory/resources will be
> > leaked if I use that pointer to cleanup old allocations. This seems to be
> > in agreement with what I observed in my debugging.
>
> Yes, that's look correct.  Note that if you create a new
> context with new resources, you have to add another cleanup
> handler to free these new resources as well.
>
> > A follow up question. After the redirect call, I am recreating the
> context
> > and restoring some of the data. However, like you mentioned I cannot
> > restore all the data. Currently, I am not accessing inaccessible data,
> > it seems to be working fine. However, in case I need to access the lost
> > data, is there another area in the request that is not disturbed by the
> > redirect call where I can save the context data?
>
> Cleanup handlers is the best way go, check the realip module and
> the ngx_http_realip_get_module_ctx() function I've mentioned in
> the previous message.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list -- nginx-devel at nginx.org
> To unsubscribe send an email to nginx-devel-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20220122/a997cc88/attachment.htm>