Hi,
I fully understand the concern and complexity of different cases. Making
any default assumption will have risks. That's why I suggested providing
config options since users themselves know their use case and whether it is
safe to retry.
Thanks!
Frank
On Tue, Jun 13, 2017 at 9:30 AM, Maxim
Hello!
On Thu, Jun 08, 2017 at 09:55:05AM -0700, Frank Liu wrote:
> I fully understand the rationale of not retrying non-idempotent requests if
> they are already sent, but in case of 429 (maybe other cases as well), I
> don't see an issue of retrying even if request is sent. It would be better
>
I fully understand the rationale of not retrying non-idempotent requests if
they are already sent, but in case of 429 (maybe other cases as well), I
don't see an issue of retrying even if request is sent. It would be better
if we can selectively do something like "proxy_next_upstream
non-idempotent
Hello!
On Thu, Jun 08, 2017 at 01:10:25AM -0700, Frank Liu wrote:
> In case of upstream returning 429, I'd like to have nginx retry next
> upstream server. Since nginx by default won't retry non-idempotent
> requests, how do I force nginx to retry when receiving 429? I imagine this
> should be th
In case of upstream returning 429, I'd like to have nginx retry next
upstream server. Since nginx by default won't retry non-idempotent
requests, how do I force nginx to retry when receiving 429? I imagine this
should be the default behavior anyway, or does nginx not care about
returning code and w
