[PATCH 2 of 3] Upstream: allow recovery from "429 Too Many Requests" response

[Maxim Dounin]

Hello!

On Wed, Mar 01, 2017 at 12:16:39PM -0800, Piotr Sikora via nginx-devel wrote:

> Hi Maxim,
> 
> > Not sure it's good idea to don't count a 429 response as a peer
> > failure.  Contrary, counting it as a failure will naturally reduce
> > load on the particular server, resulting in less rejects.
> 
> But 429 can be returned on a per request basis (think client IP
> exceeding limit_req limits, or a logged in user that's rate-limited
> based on API usage), so I'd question marking backends as failed
> because of that.

Sure, but why one would use "proxy_next_upstream http_429" then?

If one of your backends reject a requests based on client's IP / 
login, then you probably don't want nginx to retry such a request 
on other servers, as this will just allow the user to do more 
requests when you already know the limit was reached.  And it 
doesn't look like an effective way to build a system with 
distributed limits.

In contrast, if a limit affects nginx's IP and/or group of 
services on a backend, retrying on a different backend may make 
sense.  But use case suggests that 429 should be counted as 
failure.

Note well that right now only 404 and 403 are not counted as 
failures, and these are done for a very specific use case: when 
only some of your backends have relevant resources available, and 
404 is just used a signal to try other backends.  And 403 is mostly 
the same, but will appear when syncing new directories to a 
backend server.

-- 
Maxim Dounin
http://nginx.org/