1.9.13 and non_idempotent

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

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 http://nginx.org/r/proxy_intercept_errors.


Maxim D.
http://nginx.org/

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.

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]
http://mailman.nginx.org/mailman/listinfo/nginx


Maxim D.
http://nginx.org/

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

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/

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

Thanks!
Frank

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;

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/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs