[PATCH] Proxy: make timeout directives accept variables

Thibault Charbonnier 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 mailing list