1.9.13 and non_idempotent

Server NGINX
1

If I explicitly configured to retry next upstream based on a
certain http_xxx, will that stop working if a request is a POST with
1.9.13? For other http code, I like the idea of not retry if it is non
idempotent but for one http_xxx, I want retry no matter what type of
request.

Thanks
Frank

2

Hello!

On Tue, Mar 29, 2016 at 06:34:59PM -0700, Frank L. wrote:

If I explicitly configured to retry next upstream based on a
certain http_xxx, will that stop working if a request is a POST with
1.9.13?

Yes. There is no real difference between a network error and an
HTTP error returned from idempotence point of view. E.g., 502
error just means that a network error happened somewhere else.

For other http code, I like the idea of not retry if it is non
idempotent but for one http_xxx, I want retry no matter what type of
request.

Just curious - which one?

Note well that if you want finer control of how various HTTP errors are
handled, you can use proxy_intercept_errors with appropriate
error_pages configured. See Module ngx_http_proxy_module.

–
Maxim D.
http://nginx.org/

3

It’s a custom error code, think of it as if http_404, so if the first
upstream can’t handle this request , it will send “404” saying it is not
for me, please try next, nginx should then send the same request to next
upstream.

4

Hello!

On Tue, Mar 29, 2016 at 08:04:33PM -0700, Frank L. wrote:

It’s a custom error code, think of it as if http_404, so if the first
upstream can’t handle this request , it will send “404” saying it is not
for me, please try next, nginx should then send the same request to next
upstream.

Well, nginx can’t handle custom error codes in
proxy_next_upstream, so this is probably irrelevant anyway.
Though I was considered excluding http_403 and http_404 from
idempotence checks, it may make sense to do it if there are enough
such use cases.

Yes. There is no real difference between a network error and an
handled, you can use proxy_intercept_errors with appropriate

nginx mailing list
[email protected]
nginx Info Page

–
Maxim D.
http://nginx.org/

5

Does that mean by default if one upstream server is down (connect error
or
connect timeout), nginx won’t try the next server and POST request will
just fail?

Thanks!
Frank

6

Hello!

On Thu, Mar 31, 2016 at 07:46:40PM -0700, Frank L. wrote:

Does that mean by default if one upstream server is down (connect error or
connect timeout), nginx won’t try the next server and POST request will
just fail?

No. Quoting CHANGES (http://nginx.org/en/CHANGES):

*) Change: non-idempotent requests (POST, LOCK, PATCH) are no longer
   passed to the next server by default if a request has been sent

to a
backend; the “non_idempotent” parameter of the
“proxy_next_upstream”
directive explicitly allows retrying such requests.

Connect errors doesn’t imply that a request has been sent to a
backend. As long a request hasn’t been sent yet, it can be
retried to another server without any problems.

See docs here for more details:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#non_idempotent

–
Maxim D.
http://nginx.org/

7

Can you post a quick patch on how to exclude http_404?

Thanks!
Frank

8

Will this work?

— ngx_http_upstream.c.orig 2016-03-29 15:09:31.000000000 +0000
+++ ngx_http_upstream.c 2016-04-02 05:28:17.877466756 +0000
@@ -3990,6 +3990,7 @@
timeout = u->conf->next_upstream_timeout;

 if (u->request_sent

  •    && (ft_type != NGX_HTTP_UPSTREAM_FT_HTTP_404)
   && (r->method & (NGX_HTTP_POST|NGX_HTTP_LOCK|NGX_HTTP_PATCH)))
    {
    ft_type |= NGX_HTTP_UPSTREAM_FT_NON_IDEMPOTENT;
9

Hello!

On Fri, Apr 01, 2016 at 10:33:22PM -0700, Frank L. wrote:

 {
     ft_type |= NGX_HTTP_UPSTREAM_FT_NON_IDEMPOTENT;

Yes, looks correct.

–
Maxim D.
http://nginx.org/