I've never had that happen, but instead have had "intelligent" caching mess up my requests that returned 200 multiple times. Granted, most of the times it was a bad header that did not specify no-cache, but as far as I know, error codes are never cached. With 200 and caching, error body would continue to be returned for the cache's lifetime.
> It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario.
This I agree with, Javascript syntax just sucks for error handling.
Not sure what you mean about JS fetch calls. The status code doesn't determine wether or not the catch block executes. The only thing it does affect is the value of the response.ok boolean (which is true if the status code is less than 300). There are a few cases where fetch will throw an exception, but status codes aren't among them: https://developer.mozilla.org/en-US/docs/Web/API/Window/fetc...
The part about making JS fetch errors easier to catch... You consider server errors not to be errors? How is it that telling unreachable servers apart for mother errors better than telling "error" apart from success?