> It will also be returned if there are too many HTTP requests in a single day. This is similar to the HTTP 429 Too Many Requests error message.
Similar? That is excatly what 429 was made for, or not? This is weird or just lazy.
Obviously it’s bad practise to do this but I don’t think it’s a mystery why they’d want their denial to be opaque. I’m also having trouble getting that worked up about it. If its OK to return 418 as a joke it’s probably fine to return 999 to suspected crawlers.
Again I’m not really defending the practise, I think it’s bad, I can just clearly see how they ended up where they ended up.
If I wanted to mess with clients I don't like, I'd just return a random valid code.
I think if you don't want to supply even that, a better way would be to just close the connection and don't send anything back at all.
The only practical reason for a 999 error code I see is if you want to confuse the client about whether or not the response indicates an error at all. Maybe they were hoping some crawlers treat everything that's not 4xx or 5xx as "success" and so they can poison their index?
That thinking would be relatively naive though, as I think most http clients treat everything that's not 2xx as an error.
So most likely reason is probably some programmer that went through the REST fanboy phase and thought they were special.
I think this is the correct answer if a bad-mannered crawler has been identified. To take it a step further, one could do a HTTP version of a SSH Tarpit[1] although that's likely taking things too far.