Hacker News Reader

Comment by whartung | Hacker News Reader

I think the premise here is that a 4xx is an “expected” server issue, which the code may be able to handle (i.e. retry) whereas a 200 followed by a parse error is an “application problem” that they’re not prepared to handle.

A 200 may mean the payload has changed, and how would an app handle an arbitrary format change? This could well fall into the “don’t test for something you can’t handle”.

At a minimum it’ll ideally get the app to quiet down.

View on HN

> I think the premise here is that a 4xx is an “expected” server issue

That premise is incorrect, as 4xx is client errors, as in the client formatted the request wrong or anything else, and therefore it couldn't be responded to. Rate-limiting is the client hitting the server too much, and it's up the client to handle this.

5xx is for server issues.

2xx should be success in any shape or form, so clearly 2xx shouldn't be used in this case either.

I agree that 429 should just be used for it's intended purpose here, handling rate-limiting requests/responses. You can still add a body if you want, with the current quotas.

From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx.

It's not what "should" be used, it's what the author found to be effective.

Which is slightly strange because it contradicts the previous suggestion: don't be too liberal of what you accept.

I like the detail from the top comment of replying w a 429 after a many second delay. That would mitigate any retry storm.

> From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx.

But trying to handle clients who mishandle things like that is a fools errand. What client, in their right mind, would try to retry a request that is failing because of what the client is sending? In no case does that make sense, ever.

Similarly, should everything just be 200 then just in case clients mishandle redirect requests?

A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing.

People will copy random snippets from SO and smack them with a hammer until they seem to work then move on to the next thing. I've seen some incredibly stupid code out there, code I can only assume the author either didn't understand or truly didn't give a fuck about. Probably both.

> A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing.

Sure, I agree a lot with this, but that doesn't mean you and me should also do idiotic things. Lets just return correct status codes and the ones who misuse it, will misuse it :)

To be fair in some cases rate-limiting could be triggered by a server-side issue, technically there's a 529 error for that, but I can't recall seeing it used. But 4xx errors should exist as an indication to clients that there's no point immediately retrying the same request. If they're not honouring that, delaying before responding seems the most reasonable course of action.

I'm even guilty of writing client code that just retries on failing to parse the response, precisely because the server I was working with randomly would return empty/corrupt responses for no discernible reason (it was actually Amex's API sandbox). Come to think of it, perhaps it was trying to rate limit us, as it happened a lot running our integration test suites! But the fact it returned 200 and even text/html as the content type was a bit ridiculous.

Reply on news.ycombinator.com