Handling module ctx reset on internal redirect

Eran Kornblau eran.kornblau at kaltura.com
Tue Feb 14 15:50:38 UTC 2017

If I understand your description correctly, I had the same problem - I wanted to expose an internal error code
of my module as an nginx variable, so that I could write it to the access log. But after the redirect to the error page, 
the context was erased and the handler could not retrieve it.

The solution I implemented in my case was that when an error occurs, instead of saving it on the module context,
I explicitly set the value of the nginx variable (r->variables). This way the variable can be evaluated without any 
dependency on my module.

This is the code that sets the value -

The variable index is initialized right after creating the variable, here:

And the handler of this variable is now just an empty placeholder:

Hope this helps,


-----Original Message-----
From: nginx-devel [mailto:nginx-devel-bounces at nginx.org] On Behalf Of Pillai, Saju
Sent: Tuesday, February 14, 2017 5:26 PM
To: nginx-devel at nginx.org
Subject: Handling module ctx reset on internal redirect


I am new to nginx and will appreciate some insight on handling the resetting of module ctx during internal redirects.

Specifically, I have a module that runs in the HTTP_POST_READ_PHASE to build some objects in memory, which it hangs off the request object via ngx_http_set_ctx(r,..). These memory objects back new variables created by this module.

After an internal redirect, when a filter tries to access the variables, my handler is unable to find the ctx object via a ngx_http_get_module_ctx(). I see that ngx_http_core_module.c:ngx_http_internal_redirect() zeros out all module contexts during an internal redirect, and that makes sense. The (appropriate) contexts will have to be rebuilt by modules that run for that internal redirect.

Since HTTP_POST_READ_PHASE handlers dont run on a redirect, how should I setup my ctx so I can still access it after a redirect? I could create a r->pool cleanup function and hang my ctx in the ngx_pool_cleanup_t->data slot; but that seems like a workaround.



This e-mail message is authorized for use by the intended recipient only and may contain information that is privileged and confidential. If you received this message in error, please call us immediately at (425) 590-5000 and ask to speak to the message sender. Please do not copy, disseminate, or retain this message unless you are the intended recipient. In addition, to ensure the security of your data, please do not send any unencrypted credit card or personally identifiable information to this email address. Thank you.
nginx-devel mailing list
nginx-devel at nginx.org

More information about the nginx-devel mailing list