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 Dounin <mdounin@mdounin.ru> wrote:

> 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
> > if we can selectively do something like "proxy_next_upstream
> > non-idempotent-http_429;" or whatever http code that we know safe.
>
> The problem is that we don't really know if the code is safe or
> not.
>
> In general, non-idempotent requests are not retried as we
> don't know if the request was processed or not. The situation is
> obvious when we got a network error after sending a request: as
> the error might happen after the request was already processed, it
> is wise to refrain from retrying it.
>
> But what happen when we got a valid http error instead? For
> example, 502 in most cases means that there was a network error
> somewhere else. So, this basically means that 502 cannot be
> retried as well. And the other 5xx error codes are more or less
> identical: we never know what really happened, and can't retry.
>
> With 4xx errors it seems safe to assume that the request was not
> processed, and hence retrying is possible. But, for example, if
> error_page is used on the backend server, 404 might be returned
> if a network error happens and a corresponding error page cannot
> be found. Similarly, 429 might be returned if limit_req rejects a
> request to the error page.
>
> We've considered adding a logic to always retry non-idempotent
> requests in case of 4xx errors when non-idempotence handing was
> introduced. But decided to keep things simple and safe, and never
> retry non-idempotent requests. On the other hand, introducing
> configuration options to fine tune if non-idempotent requests
> should be retried for each proxy_next_upstream case seems to be
> overkill.
>
> In general, current implementation assumes the following two
> options:
>
> - non-idempotent requests are not retried;
>
> - there is a duplicate request protection in the application, so
> non-dempotent requests can be retried with "proxy_next_upstream
> non_idempotent;".
>
> This seems to be enough for most, if not all, use cases. If
> something more complex is really needed, it can be configured
> using error_page and additional error processing logic.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx