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
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel