<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>Thanks!</div><div>Frank</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 9:30 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Thu, Jun 08, 2017 at 09:55:05AM -0700, Frank Liu wrote:<br>
<br>
> I fully understand the rationale of not retrying non-idempotent requests if<br>
> they are already sent, but in case of 429 (maybe other cases as well), I<br>
> don't see an issue of retrying even if request is sent. It would be better<br>
> if we can selectively do something like "proxy_next_upstream<br>
> non-idempotent-http_429;" or whatever http code that we know safe.<br>
<br>
</span>The problem is that we don't really know if the code is safe or<br>
not.<br>
<br>
In general, non-idempotent requests are not retried as we<br>
don't know if the request was processed or not.  The situation is<br>
obvious when we got a network error after sending a request: as<br>
the error might happen after the request was already processed, it<br>
is wise to refrain from retrying it.<br>
<br>
But what happen when we got a valid http error instead?  For<br>
example, 502 in most cases means that there was a network error<br>
somewhere else.  So, this basically means that 502 cannot be<br>
retried as well.  And the other 5xx error codes are more or less<br>
identical: we never know what really happened, and can't retry.<br>
<br>
With 4xx errors it seems safe to assume that the request was not<br>
processed, and hence retrying is possible.  But, for example, if<br>
error_page is used on the backend server, 404 might be returned<br>
if a network error happens and a corresponding error page cannot<br>
be found.  Similarly, 429 might be returned if limit_req rejects a<br>
request to the error page.<br>
<br>
We've considered adding a logic to always retry non-idempotent<br>
requests in case of 4xx errors when non-idempotence handing was<br>
introduced.  But decided to keep things simple and safe, and never<br>
retry non-idempotent requests.  On the other hand, introducing<br>
configuration options to fine tune if non-idempotent requests<br>
should be retried for each proxy_next_upstream case seems to be<br>
overkill.<br>
<br>
In general, current implementation assumes the following two<br>
options:<br>
<br>
- non-idempotent requests are not retried;<br>
<br>
- there is a duplicate request protection in the application, so<br>
  non-dempotent requests can be retried with "proxy_next_upstream<br>
  non_idempotent;".<br>
<br>
This seems to be enough for most, if not all, use cases.  If<br>
something more complex is really needed, it can be configured<br>
using error_page and additional error processing logic.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>