The sad reality is that when you look at the files being requested, it’s usually scrapers looking for exploits.
You can’t have bugs if it’s always the caller fault
Deleting all the S3 buckets on my way to the exit interview
releases a change where all routes accidentally go to the error page controller
🤷♂️ They’re 4xx errors, won’t be us
All 418 error codes. We good.
if (request.ip != myip) return ErrorCodes.NotFoundAnd an ipv6 version for all you up 6 fans
if (request.ipv6 != myipv6) return ErrorCodes.NotFound3** status codes: 4000%
Oops
a pretty grafana dashboard? peak web traffic looks a lot nicer than i thought!
“Not my problem” code
Better than a 200 JSON reply containing the 4xx. “Aay it worked!” “oh.”
I’ve had this so often… very frustrating.
I like to think the 400 within a 200 is for “look, I managed to reply to you. But there is bad news”
You can give a 400 response a body though. It doesn’t stop you from replying.
This legitimately happened to me a few months ago. A vendor API was returning HTTP 200 with the error details embedded in the JSON response. It was a pain in the ass to troubleshoot.
I guess I might be evil but when I made APIs for my projects I do this, since I blindly accept the response then look at the JSON to see if it was accepted or not
Something like
if (body_has(JSON)) do_stuff_with(JSON) // including error handling if the response has an error else error_no_json()I do this since I feel like JSON errors should be separate from HTTP errors
The problem I ran into was the response returned a JSON body, but then had an “error” attribute that was returned in it that had the error details. So we were parsing the JSON and loading elements into our database. We were hitting the API passing in a datetime of when the last success job was run, so basically saying “give me everything that’s changed since I last called you.”
So yeah, eventually we noticed we were missing small chunks of data. It turned out that every time the API errored out, we’d get a valid JSON response that contained the error message, but it didn’t have the attributes we were looking for. So didn’t load anything, but updated our timestamp to say when our last successful call was.
Huge pain in the ass to troubleshoot, because the missing data was scattered with no distinguiable pattern.
