• 0 Posts
  • 15 Comments
Joined 22 days ago
cake
Cake day: March 8th, 2025

help-circle
rss

  • I get it. I’m just trying to illustrate why i like to differ between com and app errors. Now we have identified three different scenarios, all returning 404. Resource not found Data not found (client error). Data not found (server error). when we could treat them different because their nature is fundamentally different. I mean if we request a list of objects and nothing was found, because we asked for a date when there was no data, its not an error. But i suppose many still just throw around exceptions still instead of handle them properly, and it looks terrible in the log. Imo if i know the reason for a behaviour its not necessarily an error, and using an error code for a non-error makes it harder to find real errors. Maybe i’ve just been turned off by how they have been used in our legacy code. Maybe you don’t define 404 as a client side and not an error, and i guess thats fine. But its pretty counterintuitive to be a number in a list of client errors and be anyrhing but.


  • The customer expects a row to exist. The server does not find it.

    The customer sent a valid request, and it should exist according to the customer.

    The server could not find it. It can find others, but not that one, so from the server perspective it’s the client that gave the wrong id. If i always send a 404, the customer system think it did something wrong, which it didnt. Should they try to find the error on their side now, as it is a “client error”?

    If i send a 500 every time, the customer will think the server is at fault, which it is. The server just could not find that row. What if the customer actually made an error, sending the wrong id, and i send the same code every time. It will be the servers fault every time the customer makes an error, and now they will never double check their inputs.

    My point is, there is no nuance with these old codes. Obviously i will send a 500 for a caught exception and a 400 for a client error, but it is not always so easy.


  • I mean sure, in the strict meaning of the code-guides you are probably correct. Most problems stems for us at least from cross-reference issues which are normally configuration problems in the underlying system or other data-related issues. Those are often not neither the responsibility of the server or the client, and sometimes its both. There are often no code that is suitable to respond, and to just send “Bad request” when it’s a good request - does not make sense. Therefore i think it’s better to let badrequest be for bad requests, instead tell the client that sure, this is a good request but for this reason it didn’t work this time. This has to happen for it to work. Either i can do it with a simple structure in json with maybe 5 status codes and a message, or i have to figure out what 20 http status codes both i and the client has to implement and give them meaning that isn’t their intended meaning.


  • Obviously you can, and i do returm 4xx codes if the initial parsing, authentication or something else goes wrong im the controller, but once im in the next api, or any number of systems down the chain, im probably gonna return a 200 with a status with a tracking code. It’s proven, at least for us very helpful to find issues fast on both sides. To me getting a 4xx back when it’s step 6 our of 13 that is the problem in the API but the request itself is fine doesn’t seem meaningful and just makes customers assume things. I guess if every endpoint only does one thing, i’d probably do like you.



  • Honestly makes perfect sense.

    1. Message received and successfully parsed.
    2. An error occured while processing request. Ideally they would have a message in the response saying what went wrong if it is relevant for the user.

    The problem with only reacting with 500 Internal Server Error is that the user will never improve their input data, if they can do something about it. Responding with 404 is just mean as they wont know if the endpoint is not found or the database couldn’t find any data. Differentiating the communication from the processing is i.m.o the best way to do it.



  • While passing on american products in general is a good thing, not all products are equal. Signal is far better for privacy than anything in europe currently. Until there is a good option, supporting an open source non-profit company won’t give the US any profits from your usage. And that’s what really counts. To be honest, signal is the only safe system currently. What makes it unsafe is proprietary software on the clients it’s being used on like IOS or whatever android branch it’s used on.

    We really should have something, especially as privacy in europe is really in danger with the chatcontrol agenda. We need both an operating system, and safe communication made in europe, and even more importantly, EU legislation that prevents things like chatcontrol even to be considered.



  • I’ve been there twice, first time during 2008 and the security was crazy. Had homeland security already doing background check in the airport at the checkin counter, and while there i had two “VIP” searches due to connecting flights. Next time was just a few months ago, was scared they’d do some nasty searches and checks again but this time it was far more pleasant, signed a form on the internet, although it cost a bit, everything went smootly. I was suprised that the traveling was like going to all other places. The people are great, the food is great and really an overall great experience.

    I will NOT set my foot there again as long as Trump is in power and really, i was scared to say anything on the internet before going because he’d already won the election which is quite telling but since biden was still running things i felt safe taking my electronics. Now i doubt they’ll ever let me back in 😂



  • I’ve set up a reverse proxy to try out hosting a few APIs but i’m curious about best practice and haven’t found any good way to do it. Anyway, i have them running dotnet 9 on debian, and hosting them on http ports and then reverse proxying to apache that serves them externally with certbot on 443 to some real hostnames. I would really want to host them on https internally as well, but is there a neat way to “cert” them without an internal CA-service? My experience with self-signed certs are mostly that they always force me to trust the server cert in my connection strings, which is also unsafe so i just don’t bother. Is it worth working on and which is the best approach here?



  • I respect your ideal and i think its a good basic value to have, but lets be honest. Reddit has always had content moderation in one way or another but had very high level of tolerance. I remember when every second post on reddit was a huge ascii of pedobear and they had subreddits with legal yet very untasteful pictures of underage girls and bullying fat people had their own subreddit. At some point it became large enough to get large investors that doesn’t want their name next to a barely dressed 14 year old. Then TheDonald and other right wing subs was banned, so it has mostly upheld free speach for what is popular among its users for the longest of time but has never been a free speach platform. Even 4chan today is nowhere near what it used to be, for good reasons i think because i think no sane person would look at it and think, this is free speach in its prime.