Hi!

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 anywhere.

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.

Best,
Thibault
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Reply via email to