proxy_next_upstream_action to distinguish different network actions

[Shafreeck Sea]

add proxy_next_upstream_action

The directive "proxy_next_upstream error timeout" takes effect on three network actions: connection, send and recieve. In practice ,we realy want to try next upstream according to in which actions we are. For example, I do not want to try next upstream if some error occurs or timed out when recieving response from upstream, otherwise it maybe duplicate my request .
so the proxy_next_upstream_action is involved to address this problem , the directive takes one or more parameter : conn, send, recv which indicates whether we should try next upstream.
Usage:
proxy_next_upstream error timeout;
proxy_next_upstream_action conn;
Tring next upstream if error or timed out on connection.

[Jack Bauer]

I second that.

The "error" directive should be split at least into an error while sending the request and an error while receiving the response.

If a request is not sent completely to an upstream instance, it should be safe to send the same request to another upstream instance. If there is an error while receiving the response, one cannot distinguish if the request is already finished by the instance or not. Forwarding the request to another upstream instance could result in doubled data (depends on the backend).

This should be on the long-term roadmap for nginx.

[Shafreeck Sea]

So how about the idea : add proxy_next_upstream_action directive ？

[Maxim Dounin]

Highly unlikely to be introduced in this form. Some better options to selectively disable retries of non-idempotent requests are in long term plans though.

[JensRantil@…]

We are, too, interested in this. I'm somewhat surprised more people don't take this more seriously. I assume they are unaware of the fact that nginx by default retries all their PUTs, POSTs, DELETEs etc.

[usernameisalreadytaken2014@…]

PUT and DELETE are OK to automatically retry, since they are by definition idempotent.

(POST is never OK to automatically retry.)

Someone correct me if I'm wrong...

[fgonzalezaguirre@…]

We are also interested in this (and we have a current support subscription with Nginx Plus).

For any non-idempotent requests, you should have the option to configure:

proxy_next_upstream off|on if data has been written to the backend
proxy_next_upstream off|on if data has been read from the backend

If you never wrote data to the backend (or never connected in the first place), then I agree the default behavior should be to retry (and even this should be configurable for both cases). However, if you already wrote data or read data, the default action should be to return the timeout, and make it configurable for both scenarios (only written or written and read). That way you can at least configure the backend or location depending on your specific application behavior.

[marcosnils@…]

Hi Everyone,

We developed a plugin which helps to handle this case.

​https://github.com/xetorthio/nginx-upstream-idempotent

Feel free to use it or suggest any changes.

[Maxim Dounin]

The 91c8d990fb45 commit changes proxy_next_upstream logic to do not retry non-idempotent requests by default if a request has been already sent to a backend, and introduces additional proxy_next_upstream non_idempotent parameter to restore the old behaviour if needed.