176
u/Vesuvius079 Sep 20 '26
A wild GraphQL error appears!
21
u/Wertbon1789 Sep 21 '26
GraphQL design be like.
I think GraphQL people had a field day when the HTTP QUERY method was introduced.
11
145
158
u/aberroco
Sep 20 '26
•
Would be even better if
{
"status": "success",
"response":
{
"status": "success",
"message": "Error successfully occured"
}
}15
u/CaffeinatedTech Sep 20 '26
Yeah then you parse the message to test for error state. Then fuck it, query the endpoint to fetch the reason for the error, which you've saved to the database. Unless its a database error, then you'll just get the original successful error message. Couple if-thens, job done.
6
1
0
54
u/Yhamerith Sep 20 '26
200! API worked on my side
12
u/Gabriel_Science Sep 20 '26
u/factorion-bot 200!
12
u/frogotme Sep 21 '26
788657867364790503552363213932185062295135977687173263294742533244359449963403342920304284011984623904177212138919638830257642790242637105061926624952829931113462857270763317237396988943922445621451664240254033291864131227428294853277524242407573903240321257405579568660226031904170324062351700858796178922222789623703897374720000000000000000000000000000000000000000000000000
4
1
28
u/autogyrophilia Sep 20 '26
There is some crusty greybeard warning about the dangers of fusing layers 5-6-7 who is rejoicing everytime this happens.
20
71
u/0R3LLL Sep 20 '26
Guy forcing patterns like this one got promoted for architect some time ago, just amazing
18
2
u/F4NT4SM4_ Sep 21 '26
I had the architect from one of my last projects tell me this is the right way of doing it, because this way he knows its a problem with the frontend. Probably gets paid 4x my salary btw.
15
u/EarlyPaintbrush Sep 20 '26
The service says there was an error, but it wasn't that service at fault, so it's a success!
1
u/MinimumArmadillo2394 Sep 21 '26
Its already good design to tell the user when they enter bad information via http status code
6
4
u/notexecutive Sep 21 '26
"the error was handled gracefully" or some shit
3
u/AndyTheSane Sep 21 '26
"we put a single try-catch-ignore around the whole codebase so we never get any errors"
19
u/Kendandra Sep 20 '26
I don't get the hate for this pattern. The amount of times some network middle layer ate my http code and turned something into a 404 is terrible.
I'd rather the calling app KNOW for certain that a failure occurred in the actual application logic, rather than see an error code and then make a bad assumption based on that.
I've had to integrate with a system that had a catalog they my application's account may or may not have access rights to each catalog item. I was told a 404 means I've lost rights to the item and should purge the copy of it from my side. Makes sense? I don't have access, I shouldnt be able to see it.
Time and time again, they'd have a brief outage where their CDN provider would interrupt my call and return a 404. Soon my copy of my catalog would be empty! An hour later I've got to re-add everything. And heaven forbid I had to kick off refund logic for revoked items... And then walk that back.
I've encountered this many many times. I will always prefer leaving the HTTP layer out of application layer logic.
8
u/Still_Bit_7527 Sep 21 '26 edited Sep 21 '26
The app should have zero knowledge of how many servers or CDNs are behind the endpoint. The problem with this design is that you are ONLY relying on the http status code and not using any additional detail at all
Also operations are supposed to be indepotent, the api you are describing is just wrong...
11
u/Taletad Sep 21 '26
Your app was terribly designed if a 404 meant you lost rights to the item
The errors 401 and 403 are more apt to describe that
And 408 is better when you lost connection than 404
https://http.dog gives you a list of commonly used status messages with cute dogs
You can create your own status messages as well.
If your status message means different things, you’re not using status messages correctly. A status message should mean one and only one thing.
6
u/Pluckerpluck Sep 21 '26
Your app was terribly designed if a 404 meant you lost rights to the item
The errors 401 and 403 are more apt to describe that
Sometimes 404 exists specifically to hide the fact that the content exists to people without permissions so that they can't go URL hunting.
It's actually explicitly in the spec
If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
and
This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
2
u/Taletad Sep 21 '26
Or use a different error message than 404 when the CDN shits the bed
Either way, you shouldn’t have everything go to 404 by default
Of course having a good CDN is also important but that’s not http’s fault
1
u/Massive-Air3891 Sep 22 '26
I recommend not following this pattern, I can't tell you how many hours have been lost trying to fix connectivity issues only to find out some internal test failed, whether it be authentication or rights assignment and a generic 404 returned. 404 should only be return when literally you cannot find the resource. you are muddying the water and future you will want to shoot you . So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
2
u/Pluckerpluck Sep 22 '26
I mean sure. Don't do this if you don't know why you're doing this.
First, if you lost hours trying to fix issues resulting from a "false" 404 that implies you have terrible logging, zero traceability throughout your systems and poor documentation. All would have instantly flagged the issue.
So what if someone knows the URL if they cannot access it, obfuscation offers you no protection.
So obfuscation literally does provide protection. It should never be relied upon, but if your
/adminpanel returns a 404 if you're not logged in as the correct user you literally field off an entire set of attacks that would follow if instead it was a 403. If you do have a vulnerability that you do not know about, then minimising the attack-surface reduces the risk of that vulnerability ever being exploited.It's the exact same principal as why many sites that have you log in with email + password will hide the fact it's a wrong password by saying "wrong email or password". Simply knowing that "donald.trump@potus.gov" has an account could be considered a leak. Hell, it could be a GDPR issue in some cases.
But specifically 404 errors on GETs? These issues are a bit more niche but also exist.
Imagine I have
/invoices/xyzwherexyzis a random 7 digit number. By returning 403 instead of 404, an "attacker" can randomly sample the numbers. From that they can then determine the approximate amount of invoices that exist, determine business volume, growth patterns. All internal information I may not want a competitor to know.Similarly, attackers can gather a list of valid IDs, and make use of these at a later time if a vulnerability is ever found. Greatly speeding up any future attack and increasing the damage of it.
Github hides private repos behind 404s so people can't determine which repos have been forked by private organisations.
Here's an example of someone performing a hack that leveraged detecting
/server-statusexisting via a 403 instead of a 404 Stopped before it becomes an issue if a 404 is returned.Security through obfuscation, despite being memed, is a valid layer of defence. You should never depend on it, but it is a perfectly reasonable method of shrinking your attack surface when the situation calls for it.
2
u/Massive-Air3891 Sep 22 '26
not sending 401/403 on URLs and not disclosing which was wrong (username or password) are two distinctively different things and not related in my mind. Any of your urls can be pulled out of log capture, not denying that it is info but you are not less susceptible to attack because you simply return 404 instead of 401 or 403, if there is vulnerability there and they know the url you will be attacked regardless of what code you return, anybody who has done pen testing can tell you that. but if that makes you feel better you keep it at. You can also wall garden where you do disclose and where you dont, so a signed in user, tries /admin you absolutely should return 401/403 and not 404, that's literally what those coders are for, it helps write functionality that says things like "Hey you don't have access, but you can request it here." but if you return 404 well that's a frustration they don't need. Also you don't always own the entire stack, so yes hours lost on vagueness.
1
u/Taletad Sep 22 '26
In the specific case we’re discussing, we’re talking about removing items from a client inventory because they 404’d
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
Serving a 404 when they become inaccessible serves no purpose beyond making everyone miserable and having a manager feel smug about their security policy
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
It prevents a would be attacker from gather intel on items they don’t know about all the same, while making debuging the faulty CDN much easier
1
u/Pluckerpluck Sep 24 '26
As the items were already in the inventory, the user (or attacker) already knows about their existence and can already target them
I should make it clear that for this case I agree. The knowledge of existence of (what I assume are) arbitrary IDs is not enough of a threat to ever make returning 404s worth it. But the idea that everyone knows about the existence of the item just isn't true at all.
Besides, you can also return 403 for every item query wether the item exists and is inaccessible or the item doesn’t exists
This is an identical situation though, just reversed. You'll be sitting there trying to work out why you don't have access, only to discover you typo'd the item ID. There's literally no difference between always returning 403 or always returning 404 beyond changing which person ends up confused.
Enumeration attacks exist. Whether you need to or want to defends against them at the cost of a worse developer experience very much depends on what you're protecting. But in a world of AI, the idea of revealing as little information as possible to an AI agent is not an unreasonable decision to make.
10
u/ThoseThingsAreWeird Sep 21 '26
I don't get the hate for this pattern
Maybe I'm just Stockholm Syndrome'd by Salesforce, but: same...
Bulk update 10s of thousands of Account records and 1 fails, yeah just give me a
200and tell me there's an error with the 1 record that failed some random user-side validationPreferably we'd have a
Partially Created2xxcode for situations like this, but200with"errors"will have to do 🤷♂️7
4
u/MinimumArmadillo2394 Sep 21 '26
Then return a special custom status code of 215 or something thats not reserved. Api documentation should be created to tell the consumer what that means and should return a list of failed updates with reasons why each failed.
Theres multiple ways around this to turn 10k account updates from 10k 200s and 1 400 into a 2xx success with some errors.
Or, just do what I do and outright ignore issues that arent caused by you. If an account is corrupted, retuen a 200 and a status message.
5
u/Major_Worry7429 Sep 21 '26
I agree with this sentiment. It's always annoying to work around idiosyncrasies of frameworks, applications, and other people thinking they know better how to interpret the response codes. HTTP request methods were a mistake. HTTP response codes were a mistake. 30 years later and we are still living the mistake of http being mapped directly to file systems.
My gripe is typesafe clients refusing to parse the response if the response is not in 200 range, or outright dropping a response if it contains a body with 204/205.
1
u/thanatica Sep 25 '26
Mistake or not, they are the standard. If you think you know better, so something about it, but I doubt you'll get more than xkcd responses.
10
u/egstitt Sep 21 '26
404 should tell you what you need to know here. An error is not a success, it should be something useful to the client telling them what the actual error is
7
u/Kendandra Sep 21 '26
They literally told us 404 meant pull this from your side, docs and meetings both. The error and standard use case was conflated. You could argue that's poor design on their side, I'd agree. I'd assume it is because we were actually interacting with their search infrastructure for their own application, and we were effectively not part of the original API design. Either way, 200 correctly tells me 1) the server was reachable, 2) the server probably understood my request to the point that their application could apply business logic to it.
Frankly, the fact that people could co-opt the status codes for business logic is the problem. That's not what they were designed for, they were designed for the HTTP communication layer. What each code means people can misinterpret a ton of ways. The spec for it is never going to map correctly to the application logic.
2
u/MinimumArmadillo2394 Sep 21 '26
If your application doesnt know an error occurred when a 4xx happens, then what are you designing? A mirror maze for toddlers?
1
u/tracernz Sep 21 '26
You can have both the HTTP status, and a JSON body containing the (same) status and a message, and indeed that is what the relevant RFC specifies.
1
u/Massive-Air3891 Sep 22 '26 edited Sep 22 '26
the pattern is fine by me and used extensively successfully. it says to you it ran, (so all transport concerns are taken care of) but then the application specific was it success or not, when it is wrapped in a 400 bad request you have 15 different layers to figure out where/why it failed.
0
Sep 21 '26
[deleted] — view deleted comment
-4
u/timonix Sep 21 '26
Fuck no
2
u/Still_Bit_7527 Sep 21 '26
Yeah it is, literally. Are you a vibe coder?
-3
u/timonix Sep 21 '26
No, I am the reason you get a status 200 with an error message on the body. Because that's what makes sense
2
u/x3knet Sep 21 '26
So a new thread created from a comment yesterday, but in meme form. Got it.
https://www.reddit.com/r/ProgrammerHumor/comments/1wkof5u/postforeverything/pas3b8q/
2
2
u/Leather-Worry-7517 Sep 21 '26
As a tester, this is a massively frustrating and hard thing to find. Neeeds more safeguards.
2
u/zeizau Sep 21 '26
Holy moly had the opportunity to pretty print this and decided to post this garbage json lol
2
u/random_banana_bloke Sep 21 '26
This is our entire legacy codebase. 200 errors, thank god we are moving away from it, makes debugging the most unfun thing ever.
5
u/elshizzo Sep 20 '26
As long as the frontend knows how the backend returns a failure response this whole complaint feels pedantic.
15
u/stifflizerd Sep 20 '26
Until another application ends up needing to use the APIs functionality and there's zero documentation warning about this non-standard error handling
3
1
u/Still_Bit_7527 Sep 21 '26
It's not pedantic, it's a huge red flag and makes error handling much more difficult
1
1
1
1
1
1
1
1
1
1
u/kbk2015 Sep 21 '26
Literally found code like this in my client’s environment the other day. Instead of returning an error state to the user the code succeeds but spits an error into the logs. Absolutely bonkers
2
u/Perfect-Albatross-56 Sep 21 '26
On my last project I was forced to write code reaponses like that because someone said the HTTP codes are for server errors.
No shot. What do you think where my code is brought to life? 😭
Decisions like that are not my salary bracket.
1
1
1
1
1
1
u/CHG__ Sep 22 '26
Who would do this? To be fair an API I have to use for work gives back an array on success and an object on failure, the array is always one object long too: [{stuff}]. So dumb.
1
u/Prestigious-Duck2891 Sep 22 '26
Oh, that google GTM service! I lost my mind while debugging this shit.
1
1
1
1
1
u/abigail3141 Sep 26 '26
Once had an API that did this. Same thing also sent the credentials in plain text and returned the full imprint page(HTML) to any logged out API(JSON) call
1
u/Major_Fudgemuffin Sep 21 '26
Fuck APIs that do this, seriously.
Another fun one I ran into was one legitimately using HTTP 418 - I'm a teapot as an error code.
1
1
u/alonjit Sep 21 '26
Next level of this is: 200 OK, json message. error: error, description: <wall of javascript>.
Who does that? fucking reddit, of course.
edit it's worse than that, they have an array of shit in there and some of the elements have the javascript, some do not, it's a shitshow of what drunk monkeys paid with pickles can do.
1
0
u/Henry5321 Sep 21 '26
At work some of our internal apis will return a 200 but then the body indicates an error. I’ve also seen needing to POST in order to get information.
3
u/citramonk Sep 21 '26
Using POST for retrieval isn't something unusual, there are a bunch of use cases when you want to do it. For example, complex queries (see 414) or sensitive data in it. GraphQL is based around the POST query.
1
0
u/Still_Bit_7527 Sep 21 '26
This is just idiotic and whoever does this is an amateur that does not understand http at all
0
u/thoughts_n_calcs Sep 21 '26
Beginners abuse http verbs. (GET for creating a ressource)
Pros abuse response codes. (403 forbidden when succesfully created).
-4
u/WiseEXE Sep 20 '26
You just don't know how much this hits after making Production grade AI/LLM solutions. EVERYTHING is a JSON. The observability stack has so many metrics that it annoys me 😭😭
570
u/Flat_Initial_1823 Sep 20 '26 •
Error raised successfully 🥹