Hello!
On Wed, Feb 11, 2015 at 2:58 PM, David Birdsong wrote:
> So If I set
> ngx.ctx.f = {foo='bar'}
> ngx.req_set_uri('/newlocation', tru)
> in rewrite_by_lua
> will ngx.ctx.f be nil in '/newlocation' or will it have the value of that
> table?
>
Not really. Even though the nginx core does not clear the C modules'
ctx on the C land, ngx_lua explicitly clears its own ctx data for
consistency with other (more normal) internal redirects.
> I totally get that, but there are data whose lookups costs I'd like to pay
> only once and that data remain pertinent throughout the request on any given
> connection. In my case, rewrites exist to get out of error_page locations
> which then get to try other backends given the data that was stored at the
> beginning of the request allows a particular request to continue.
>
Better avoid doing any complicated things after error_page is
triggered. It is known to cause bad issues in some cases (well, issues
in the nginx core, having nothing to do with ngx_lua though). Try
redesigning your request handling flow.
Basically one should never do any heavy-lifting before jumping to the
final location doing the real work.
> Agreed, although admittedly the session ID which we pass back and forth in
> headers is not that different from data stored in querystring or URI.
>
Abusing headers is a valid hack for this as well. Having said that,
it's hard to maintain and should be eliminated if possible.
> Session ID's are created at a higher layer in my stack and get passed back
> and forth in headers. I was simply providing it as an example piece of data
> that could be used to key into a module level table that I would initialize
> and maintain.
>
Though it's an undocumented feature, you can use the Lua global
variable __ngx_req to identify the current request, no matter how many
times internal redirects happen in the request's lifetime. Mind you,
it is a lightuserdata pointing to the underlying ngx_http_request_t
struct. Well, it's just another hack :)
Regards,
-agentzh
