> There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status cod

> There's AFAIK no standardized strategy to deal with the different status code While I was a bit too over-broad in my generalizations of 4xx vs 5xx status codes when it comes to retries, the gist is still the same. The specification does specifically call out when it's okay to retry and when it isn't. And it also specifically calls out when it's okay for intermediate servers and browsers to cache responses and when it isn't. In the case being discussed, 500 is specifically the correct error code because it cannot be cached and can be retried. That's not the case for 409 or 429, which either cannot be retried automatically (409) or can be cached (429). 402 is, IIRC, underspecified and shouldn't be used. 403 specifically states that the request should not be retried. It's important to make a distinction between the user/application and the user agent when we talk about retries. The user agent is the program or library that implements the HTTP spec. You seem to be talking about the former, who is always capable of retrying a request when they feel circumstances have changed enough for the request to succeed. But user agents are intentionally dumber. They can't resolve conflicts, fix permissions or do anything outside of the logic dictated by the spec. And they have much more limited license to retry 4xx responses or cache 5xx responses.