Http 500 OK

Thank you HP!

yes that can ruin your perfectly fine day

Reminds me of:
Code: 200
Body:
{ responseCode : "500", message: "Fatal error!"}

And I wish I made that one up entirely.

@heyheni I wouldn't mind if it were some rookies releasing their startup -- that's alright, they are dogges who have no idea what they're doing.

But this is in the response I got in a HP Performance Center 12.63.

An HP product that our client is paying >$10k daily. A tool that dares to call itself "industry standard".

@Makenshi "But it makes branching easier!!11"

No, it makes everything worse.
Fix. your. shit.
🤬

Request failed successfully

This can't be some idiotic "best practice" or whatever. There's no point to it, potential changes to behavior are exclusively bad. This is a pure and naked fuckup.

@Makenshi That is perfectly fine. The request itself succeeded and you got a valid json response. You got an application level error. Not a hyper text transport error.
Sure it sometimes is handy to (ab)use http status codes to refect the application responses but it is not necessary or always the best solution or even possible on some stacks.

@hjk101 this

@hjk101 it's not quite fine. Applications, integrations, network stack heavily rely on response codes. Keep fucking them up and, say, nginx will kick your app servers out of the pool.

The request succeeded - you can tell that by the response code.

Response messages are often times of less importance. But I'd strongly if that's the case for response codes.

Standards are there for a reason.

@hjk101 No, it isn't fine. 500 is literally the code for "Something has gone wrong on the server side". This includes the applications running on it. There are other codes, if the request itself is malformed.

Giving back 200, if any server side error happens, is just wrong. Especially when you return the correct error code embedded in some JSON.

@hjk101 What would warrant a 404 in your book? Meaningless paths only? Assuming that APIs don't reflect the implementation, how is
example.com/not-a-resource
different from
example.com/users/not-a-user

@Makenshi So your argument is that 500 has to be reserved for http only... It clearly would have been fine if they picked error code 5. It's not linked to http nor is it standardized it is an application defined error and they can have valid reasons to do it.

I used to think the same until I had to work with a service that did monitoring really well. If http errors occur something is wrong with the moving transport layers (loadbalacers, proxies, webservers, gateways, etc) if a http 500 occurred the service crashed so hard it could not formulate a valid response. Different teams for different responsibilities. This is not an issue because all responses are documented really well and are consistent.

@Lor-inc it is not my book. I've never done this. But to answer your question I think only missing endpoints where giving a 404 and you get a application specific error if you malform your request (like non existent resources)

@hjk101 afaik all http codes are application codes. They operate on application layer of osi. There are only a very few 4xx errors that might suggest smth other might be off than the application and a few 5xx errors [502, 504] suggesting networking [although might mean app errors too]. But basically all the http response codes revolute around the application. From the top of my head only 400 means possible protocol error. And 101 is directly proto-related.

And yes, these response codes ARE standardised :)

@netikras Of course you are right in osi. But that model is kinda useless when describing a webstack. When did you need to grab the osi model on AWS and go "look this one is on connection layer and the rest well all application layer, model completed!"?
http is standardized. REST is not. From a rest api point of view http is just convenient data transport vehicle.

I use http response codes myself and try to get as close to it's meaning as I can. Sometimes that is easy and sometimes that is hard, it is never required.

@netikras by the way I was only talking about Makenshi's example. Not your original post. 500 OK (or any other description deviation) is a cardinal sin.
My god I would be pissed.

@netikras sorry mate I completely missed your first reply to my first comment. In the first paragraph you basically describe my whole point.

If a programmer makes an error so a lot of 500 errors are generated. Nginx would boot all backends resulting in a complete outage. And longer downtime due to healthy/recovery conditions that have to be met. If backend application problems are only reported to the code team they can fix it efficiently and only had a partial outage.

"when did you need to grab the osi model on aws" <-- far too many times than I'd like to :) elb/alb, k8s, aws throttling, rds, dns/r53,... I'm fighting those windmills daily. At no higher level than transport :) I'm evaluating situations even at link layer, when load-testing aws-located services

@hjk101 No, my issue is not with reusing 500. Far from it. My issue lies with returning 200 while the called application e. g. raises an exception. In this situation the server should return 500, as this clearly indicates an server side error.

Instead in my particular example, it _always_ returned 200, while relaying on some custom error reporting technique that offers no benefit.

tl; dr;
The response code should reflect the outcome of the request.

The app I work on returns OK as the status text no matter the code. It's not ideal but I've never pushed for it to be fixed. The status text is only ever meant to be read by humans and in my case it's only ever seen by developers working on the app who know what http codes mean

@M3m35terJ05h I agree.

But as a developer, when reading HTTP 500 OK, how do you know which is wrong: status code or message? :) I know you could assume that a dev set the wrong status message. But you cannot know that. It could be the other way around

@netikras the status code is the source of truth. Simply because that's what other programs are going to look at. A 500 isn't suddenly not a 500 because the status text says OK. The status text is meaningless. Says right there in the spec.

@M3m35terJ05h Libraries do follow specs, I can agree with you on that. I also agree with you that status code MUST be the source of truth.

However libraries also set the default message along with the code. If a dev decided to change that behaviour the library is no longer in charge - the dev is. So I cannot ever be sure whether the dev made a mistake in setting a message or in setting a code.

Yes, all applications rely on status code. But this dissonance suggests the code _might be_ (not necessarily IS) wrong.

@netikras I suppose a server could mistakenly return the wrong code. But that would be very bad.

What happens in my example is the framework sets default headers and status code/text at the start of a request and we only change the code. I think someone assumed at one point the framework would automatically set the text based on the code

@hjk101 http is an application layer protocol, transport layer are protocols like udp and tcp

@M3m35terJ05h It really should though.

@matt-jd
Read my other comments please. OSI is not relevant here and things are not as rigid as the model once presumed (just look at TLS).

You can have multiple transport layers in this case I ment it as described for example by http://googleapis.github.io/google-...

Technically you can even implement an entire tunnel protocol on top of DNS. We can all call it application layer but that is not very descriptive now is it.

@hjk101 I did read them and I stand by that if you have a common/standard definition you should stick to it, perhaps add an application meta layer if needed. In addition the transport layer http it seems to me that they either implemented it in the transport layer meaning not utilising udp or tcp. If not it is still an application layer protocol. Just because the various applications have various interaction it does not impact the layers beneath, that is the whole point of it

@hjk101 @matt-jd
IMO it depends on the perspective.

If you are running an app on a 20GB-RAM laptop, how much memory does the app have?
If you run that app in a VM on that laptop?
If you run your app in a container in that VM?
If you run your app in a JVM in that container?

It depends on the perspective.

VPNs, ssh, other apps can create a virtual link layer (and the rest of the upper layers) over another transport or application layer and even nest them further.

If you are debugging VPN issues you have to account for all the levels of layers. So the OSI model still stands

Just my 2¢

@matt-jd I did use a common definition. Problem is you don't understand context. A single word can point to different things in different contexts. In your head IP can only stand for Internet protocol, you will have a weird conversation with a chip builder as they have been using it for instruction pointer before networking was invented. That you don't hear it everyday doesn't mean they can't use IP anymore.

Layers ideally separate concerns. OSI Application layer is meaningless here because it does not separate the stuff that matters. Sure somewhere TCP is used just like IP and MAC non of it is an concern in this discussion.

Bringing up application layer of osi when describing a specific application implementation is the same as yelling it's communication when trying to talk networking architecture.

@netikras exactly