user: Roman Arutyunyan <arut(a)nginx.com>
date: Thu Feb 22 13:16:21 2018 +0300
Generate error for unsupported IPv6 transparent proxy.
On some platforms (for example, Linux with glibc 2.12-2.25) IPv4 transparent
proxying is available, but IPv6 transparent proxying is not. The entire feature
is enabled in this case and NGX_HAVE_TRANSPARENT_PROXY macro is set to 1.
Previously, an attempt to enable transparency for an IPv6 socket was silently
ignored in this case and was usually followed by a bind(2) EADDRNOTAVAIL error
(ticket #1487). Now the error is generated for unavailable IPv6 transparent
src/event/ngx_event_connect.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diffs (20 lines):
diff -r aa60f5799a4c -r 8b70d4caa505 src/event/ngx_event_connect.c
--- a/src/event/ngx_event_connect.c Thu Feb 22 12:42:29 2018 +0300
+++ b/src/event/ngx_event_connect.c Thu Feb 22 13:16:21 2018 +0300
@@ -388,7 +388,16 @@ ngx_event_connect_set_transparent(ngx_pe
+ ngx_log_error(NGX_LOG_ALERT, pc->log, 0,
+ "could not enable transparent proxying for IPv6 "
+ "on this platform");
+ return NGX_ERROR;
#endif /* NGX_HAVE_INET6 */
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
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.
quite a while ago someone else already found the problem that the timeouts
use system time rather than a monotonic clock:
I updated/fixed the patch  there a while ago already and have this
successfully deployed on ~50 devices since then.
Any chance to get this included now? Or is there still something missing?