[PATCH] Proxy: make timeout directives accept variables
thibaultcha at fastmail.com
Tue Jan 31 18:17:36 UTC 2017
On 1/31/17 8:00 AM, Maxim Dounin wrote:
> You may want to provide more details on what problem you are
> trying to solve.
The use-case was originally to use a longer proxy_read_timeout on
certain upstream locations without duplicating too much configuration
(our location block). I then thought it would be nice to have for other
timeout directives as well, and eventually reuse the code in other
modules as you suggested, so timeout directives could support variables
> I can't say I like the patch as it introduces a lot of code
> without obvious reasons. Not to mention it only covers proxy,
> while there are also memcached, fastcgi, scgi, and uwsgi.
It is a bit verbose indeed. The reasoning behind it is that
ngx_http_proxy_timeout and ngx_http_proxy_compile_timeout could
eventually be moved to ngx_http_script.c and reused in other locations
like you mentioned. I can take care of it if you deem it necessary.
Another reason for the verbosity is that I originally used
ngx_http_set_complex_value_slot, but by doing so, we would lose proper
conf error messages when parsing a plain timeout such as
'proxy_read_timeout foo;'. This patch tries to preserve an identical
behavior when such directives do not contain a variable.
> Just a side note: this is certainly wrong, it should follow the
> same rules as normal parsing of the directive.
My bad, I assumed it would be more efficient to avoid ngx_parse_time
when possible. I will change this.
More information about the nginx-devel