Greetings nginx developers, The root cause analysis for a bug I observed during development of some custom nginx module code turns out to be an unfortunate interaction between sub-requests and indexed variable lookups using ngx_http_get_indexed_variable(). We're based on nginx 1.13.6.
The sequence of events is: - Main request arrives and triggers an access-phase sub-request. Main request includes request variable "x=blah", but sub-request does not. - Sub-request arrives at custom module's header filter - Custom module looks up variable "x" with ngx_http_get_indexed_variable(), and it is not found in the sub-request. This causes the "not_found" flag to be set in the sr->variables var cache for variable "x", but because ngx_http_subrequest() shallow copies r->variables from parent request to sub-request, the not_found flag change affects the main request's r->variables too. - Sub-request completes, main request is allowed to progress and arrives at custom module's header filter - Custom module again looks up variable "x" with ngx_http_get_indexed_variable(), and even though "x" is present in r->args and I've confirmed can be found by ngx_http_arg(), ngx_http_get_indexed_variable() sees the not_found flag, does not refresh the variable cache and returns the poisoned ngx_http_variable_value_t. There are ways to deal with this in our custom code, but it seems like a fundamental problem in the current design of the sub-request mechanism and I'm thinking that it may be appropriate to address this in the nginx core code e.g. by deep copying r->variables in ngx_http_subrequest(), or by somehow tracking when to invalidate the ngx_http_variable_value_t flags and refresh the r->variables cache. Thoughts? Cheers, Lawrence
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
