Sending HTTP status code 200 with error info in the body

Status code: 200
Content-Type: application/json
Body: {"error": true, "responseCode":400 }

I love this meme, had to share it 😂

So I got the job. Here's a story, never let anyone stop you from accomplishing your dreams!

It all started in 2010. Windows just crashed unrecoverably for the 3rd time in two years. Back then I wasn't good with computers yet so we got our tech guy to look at it and he said: "either pay for a windows license again (we nearly spend 1K on licenses already) or try another operating system which is free: Ubuntu. If you don't like it anyways, we can always switch back to Windows!"

Oh well, fair enough, not much to lose, right! So we went with Ubuntu. Within about 2 hours I could find everything. From the software installer to OpenOffice, browsers, email things and so on. Also I already got the basics of the Linux terminal (bash in this case) like ls, cd, mkdir and a few more.

My parents found it very easy to work with as well so we decided to stick with it.

I already started to experiment with some html/css code because the thought of being able to write my own websites was awesome! Within about a week or so I figured out a simple html site.

Then I started to experiment more and more.

After about a year of trial and error (repeat about 1000+ times) I finally got my first Apache server setup on a VirtualBox running Ubuntu server. Damn, it felt awesome to see my own shit working!

From that moment on I continued to try everything I could with Linux because I found the principle that I basically could do everything I wanted (possible with software solutions) without any limitations (like with Windows/Mac) very fucking awesome. I owned the fucking system.

Then, after some years, I got my first shared hosting plan! It was awesome to see my own (with subdomain) website online, functioning very well!

I started to learn stuff like FTP, SSH and so on.

Went on with trial and error for a while and then the thought occured to me: what if I'd have a little server ONLINE which I could use myself to experiment around?

First rented VPS was there! Couldn't get enough of it and kept experimenting with server thingies, linux in general aaand so on.

Started learning about rsa key based login, firewalls (iptables), brute force prevention (fail2ban), vhosts (apache2 still), SSL (damn this was an interesting one, how the fuck do you do this yourself?!), PHP and many other things.

Then, after a while, the thought came to mind: what if I'd have a dedicated server!?!?!?!

I ordered my first fucking dedicated server. Damn, this was awesome! Already knew some stuff about defending myself from brute force bots and so on so it went pretty well.

Finally made the jump to NginX and CentOS!

Made multiple VPS's for shitloads of purposes and just to learn. Started working with reverse proxies (nginx), proxy servers, SSL for everything (because fuck basic http WITHOUT SSL), vhosts and so on.

Started with simple, one screen linux setup with ubuntu 10.04.

Running a five monitor setup now with many distro's, running about 20 servers with proxies/nginx/apache2/multiple db engines, as much security as I can integrate and this fucking passion just got me my first Linux job!

It's not just an operating system for me, it's a way of life. And with that I don't just mean the operating system, but also the idea behind it :).

--- HTTP/3 is coming! And it won't use TCP! ---

A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!

Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.

Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)

The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.

Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.

We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.

Thank you for reading!

Me: We should change the http response code to anything but 200 OK in the error response case of our API.
Other dev: No, it's fine.
Me: Why?
Other dev: The client successfully receives an error message.
Me: ┻━┻ ︵ヽ(`Д´)ﾉ︵ ┻━┻

Fun fact.

The HTTP error 451 means "content is not available because of legal reasons".

The name comes from Ray Bradbury's book Fahrenheit 451, which is about a dystopian society where books and literature are censored by the government.

!rant

This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.

I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.

- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...

This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.

RE: Why I punched Dave
In my defense to the accusation against me punching back end developer dave in the face, look at the following response:
HTTP 1.1
status: 200
mesaage: OK
body: {
"success": "false",
"message": "error"
}

http 500 internal server error

Best HTTP 404 Not Found Error Ever !!

404 wall not found

Explaining HTTP status codes when the pressure is too high.

The guy in the blue shirt shows us a real life implementation of HTTP error 418 I'm a teapot

Spent most of the day debugging issues with a new release. Logging tool was saying we were getting HTTP 400’s and 500’s from the backend. Couldn’t figure it out.

Eventually found the backend sometimes sends down successful responses but with statusCode 500 for no reason what so ever. Got so annoyed ... but said the 400’s must be us so can’t blame them for everything.

Turns out backend also sometimes does the opposite. Sends down errors with HTTP 200’s. A junior app Dev was apparently so annoyed that backend wouldn’t fix it, that he wrote code to parse the response, if it contained an error, re-wrote the statusCode to 400 and then passed the response up to the next layer. He never documented it before he left.

Saving the best part for last. Backend says their code is fine, it must be one of the other layers (load balancers, proxies etc) managed by one of the other teams in the company ... we didn’t contact any of these teams, no no no, that would require effort. No we’ve just blamed them privately and that’s that.

#successfulRelease

IBM

I have replied to them with scripts, curl commands, and Swagger docs (PROVIDED TO SUPPORT THEIR API), everything that could possibly indicate there's a bug. Regardless, they refuse to escalate me to level 1 support because "We cant reproduce the issue in a dev environment"

Well of course you can't reproduce it in a dev environment otherwise you'd have caught this in your unit tests. We have a genuine issue on our hands and you couldnt give less of a shit about it, or even understand less than half of it. I literally gave them a script to use and they replied back with this:

"I cannot replicate the error, but for a resource ID that doesnt exist it throws an HTTP 500 error"

YOUR APP... throws a 500... for a resource NOT FOUND?????????!!!!!!!!!! That is the exact OPPOSITE of spec, in fact some might call it a MISUSE OF RESTFUL APIs... maybe even HTTP PROTOCOL ITSELF.

I'm done with IBM, I'm done with their support, I'm done with their product, and I'm DONE playing TELEPHONE with FIRST TIER SUPPORT while we pay $250,000/year for SHITTY, UNRELENTING RAPE OF MY INTELLECT.

Yesterday the web site started logging an exception “A task was canceled” when making a http call using the .Net HTTPClient class (site calling a REST service).

Emails back n’ forth ..blaming the database…blaming the network..then a senior web developer blamed the logging (the system I’m responsible for).

Under the hood, the logger is sending the exception data to another REST service (which sends emails, generates reports etc.) which I had to quickly re-direct the discussion because if we’re seeing the exception email, the logging didn’t cause the exception, it’s just reporting it. Felt a little sad having to explain it to other IT professionals, but everyone seemed to agree and focused on the server resources.

Last night I get a call about the exceptions occurring again in much larger numbers (from 100 to over 5,000 within a few minutes). I log in, add myself to the large skype group chat going on just to catch the same senior web developer say …
“Here is the APM data that shows logging is causing the http tasks to get canceled.”

FRACK!

Me: “No, that data just shows the logging http traffic of the exception. The exception is occurring before any logging is executed. The task is either being canceled due to a network time out or IIS is running out of threads. The web site is failing to execute the http call to the REST service.”

Several other devs, DBAs, and network admins agree.

The errors only lasted a couple of minutes (exactly 2 minutes, which seemed odd), so everyone agrees to dig into the data further in the morning.

This morning I login to my computer to discover the error(s) occurred again at 6:20AM and an email from the senior web developer saying we (my mgr, her mgr, network admins, DBAs, etc) need to discuss changes to the logging system to prevent this problem from negatively affecting the customer experience...blah blah blah.

FRACKing female dog!

Good news is we never had the meeting. When the senior web dev manager came in, he cancelled the meeting.

Turned out to be a hiccup in a domain controller causing the servers to lose their connection to each other for 2 minutes (1-minute timeout, 1 minute to fully re-sync). The exact two-minute burst of errors explained (and proven via wireshark).

People and their petty office politics piss me off.

Always a very descriptive message.

Keeping it clean and simple...

HTTP Error 413: That’s what she said!

Senior colleagues insisting on ALWAYS returning HTTP status 200 and sticking any error codes in the contained JSON response instead of using 4×× or 5×× statuses.

Bad input? Failed connections? Missing authorization? Doesn't matter, you get an OK. Wanna know if the request actually succeeded? Fuck you, parse potential kilobytes of JSON to get to the error code!

Am I the asshole or is that defeating the purpose of a status code?!

Intern's CV says they have technical skills with MS Office, MySQL and JavaScript. Last month I let my manager know that this intern doesn't really know anything, so we let her do a Freecodecamp course, after which she still cannot build a basic HTML and CSS page and doesn't understand the relationship between HTML and CSS.

My manager bought her a Laravel course for beginners and today I discovered that she also doesn't understand databases, because she tried to enter an alphabetic character into a column that only accepts integers. She doesn't read/understand the error codes thrown by the application.

She tried to access a route which she created in her Laravel app by accessing it via the phpmyadmin dashboard and called me and wasted my time by asking me why her route isn't working. She literally does not understand how computers work, or how the HTTP protocol works, even less so how a file structure works. She cannot translate abstractions to practical solutions.

She either deliberately lied on her CV to get a job, or she's just really dumb and doesn't understand what the term "technical skills" mean.

I've told my manager multiple times how I think she's in the wrong job, but they keep pushing things beyond her capabilities onto her desk. I was told I'd get an intern to help me with my work load, but I got signed up into an experiment I did not consent to (manager's words, it's an experiment to help uplift people with bad degrees and a poor background). I am not a good teacher, I hate doing it.

what the bloody fuck is this?

++ if you get it...

HTTP Error Code 420: "Enhance Your Calm"

>Download a mod from Nexusmods
>2,1GB
>200kbps connection
>gets to 90% after 3 hours
>fails with http 416 error
>???
>Check file integrity
>Fails horrendously.
>fml.

[Post marked as: Random]
So that's what they mean by the HTTP error code 418: I'm a teapot.

About browsers and whole SSL CERT thing...

Most likely everyone here noticed, that https site with broken certificate will throw these big red warnings, in your face and there is so much wording like "ITS NOT SECUREEEE" or "ITS HACKEDDD" almost like it was written by passionate fanatic.

But when you are on plaintext http browsers reaction is like ¯\_(ツ)_/¯
Even if you have plaintext with password, it will for example in chromium put small little red thingy that almost no one notices.

I believe that broken cert with some error like invalid date is MORE secure than plaintext password, yet still there is this hypocracy with browsers...

I dont say that broken SSL cert is good, or something, Im just pointing out contrast of "broken" https vs plain http.... One looks for casual Joe like end of the world is coming and second is bearly noticable. Da fuck?

I disagree with this approach

Hi lil puppies what's your problem?

*proxy vomits*

Have you eaten something wrong....

*proxy happily eats requests and answers correctly*

Hm... Seems like you are...

*proxy vomits dozen of requests at once*

... Not okay.

Ok.... What did u you get fed you lil hellspawn.

TLS handshake error.

Thousands. Of. TLS. Handshake. Errors.

*checking autonomous system information*

Yeah... Requests come from same IP or AS. Someone is actively bombing TLS requests on the TLS terminator.

Wrong / outdated TLS requests.

Let's block the IP addresses....

*Pats HAProxy on the head*

*Gets more vomit as a thank you no sir*

I've now added a list of roughly 320 IP adresses in 4 h to an actively running HAProxy in INet as some Chinese fuckers seemingly find it funny to DDOS with TLS 1.0... or Invalid HTTP Requests... Or Upgrade Headers...

Seriously. I want a fucking weekend you bastards. Shove your communism up your arse if you wanna have some illegal fun. ;)

For once I'm actually relieved Stackoverflow is down, when I opened this page I immediately started reading the code out of habit - for a few seconds I was like "holyshit what the fuck have you gotten yourself into this time!? I was googling syntax...".

The only reason I looked up in the end to realize I'm a few sandwiches short of a picnic is that after a few seconds the color scheme made my eyes bleed and I wanted to know wtf was going on with the font. I think I've had enough internet for one day...

HTTP/1.1 420 "Error: Programmer is too stoned to repsond."

"200 Internal Server Error"

Yep, I did that. Because the lousy crapheads I work with were too lazy to handle any other HTTP status so anything else breaks the whole thing. And it's a pain to roll out another release of their part of the backend so "this isn't a priority". Also, they don't feel the need to check the JSON body of the response for the "status":"ok"/"fail" because what could ever go wrong, right? I effectively have no way of conveying to them that there was an error on this end of the API so they show success toast on the frontend irrespective of what really happened.

Boss: "So I'm taking the next week off. In the mean time, I added some stuff for you to do on Gitlab, we'd need you to pull this Docker image, run it, setup the minimal requirement and play with it until you understand what it does."

Me: "K boss, sounds fun!" (no irony here)

First day: Unable to login to the remote repository. Also, I was given a dude's name to contact if I had troubles, the dude didn't answer his email.

2nd day: The dude aswered! Also, I realized that I couldn't reach the repository because the ISP for whom I work blocks everything within specific ports, and the url I had to reach was ":5443". Yay. However, I still can't login to the repo nor pull the image, the connection gets closed.

3rd day (today): A colleague suggested that I removed myself off the ISP's network and use my 4G or something. And it worked! Finally!! Now all I need to do is to set that token they gave me, set a first user, a first password and... get a 400 HTTP response. Fuck. FUCK. FUUUUUUUUUUUUUUUUUUUCK!!!

These fuckers display a 401 error, while returning a 400 error in the console log!! And the errors says what? "Request failed with status code 401" YES THANK YOU, THIS IS SO HELPFUL! Like fuck yea, I know exactly how t fix this, except that I don't because y'all fuckers don't give any detail on what could be the problem!

4th day (tomorrow): I'm gonna barbecue these sons of a bitch

(bottom note: the dude that answered is actually really cool, I won't barbecue him)

I made a functional parsing layer for an API that cleans http body json. The functions return insights about the received object and the result of the parse attempt. Then I wrote validation in the controller to determine if we will reject or accept. If we reject, parse and validation information is included on the error response so that the API consumer knows exactly why it was rejected. The code was super simple to read and maintain.

I demoed to the team and there was one hold out that couldn’t understand my decision to separate parse and validate. He decided to rewrite the two layers plus both the controller and service into one spaghetti layer. The team lead avoided conflict at all cost and told me that even though it was far worse code to “give him this”. We still struggle with the spaghetti code he wrote to this day.

When sugar-coating someone’s engineering inadequacies is more important than good engineering I think about quitting. He was literally the only one on the team that didn’t get it.

Oh damn can't find them

Just found this HTTP response.

Status Code:
200 - OK

Body:

{
status: "success",
response:
{
status: "error",
}
}

Not Found

I just got pissed off when someone on my team asked me how to start a web server on port 8080 (needed for network port testing)

I check the port get 404. 🤔🤔🤔

Spend half an hour explaining to them about ports and how there's already a week server running... And that 404 is a HTTP Status code.

I'm pretty sure she works on our webapp and maybe even REST APIs...

New grad but still.... Not recognizing a 404?

Maybe those pretty 404 pages these days make the realizing that it's a fucking web server error response harder....

Any enterprise web service which ignores http standards. If you have a Fucking error return 500 not 200 with an error string you f--k

If an http request can't perform the requested operation, should server send 500 error code? Or 200 with status and status message in response?

Isn't 500 used only for unhandled exceptions on server side?

When the HTTP status = 200, but the response body says error 400....

In today's episode of kidding on SystemD, we have a surprise guest star appearance - Apache Foundation HTTPD server, or as we in the Debian ecosystem call it, the Apache webserver!

So, imagine a situation like this - Its friday afternoon, you have just migrated a bunch of web domains under a new, up to date, system. Everything works just fine, until... You try to generate SSL certificates from Lets Encrypt.

Such a mundane task, done more than a thousand times already... Yet... No matter what you do, nothing works. Apache just returns a HTTP status code 403 - Forbidden.

Of course, what many folk would think of first when it came to a 403 error is - Ooooh, a permission issue somewhere in the directory structure!

So you check it... And re-check it to make sure... And even switch over to the user the webserver runs under, yet... You can access the challenge just fine, what the hell!

So you go deeper... And enable the most verbose level of logging apache is capable of - Trace8. That tells you... Not a whole lot more... Apparently, the webserver was unable to find file specified? But... Its right there, you can see it!

So you go another step deeper and start tracing the process' system calls to see exactly where it calls stat/lstat on the file, and you see that it... Calls lstat and... It... Returns -1? What the hell#2!

So, you compile a custom binary that calls lstat on the first argument given and prints out everything it returns... And... It works fine!

Until now, I chose to omit one important detail that might have given away the issue to the more knowledgeable right away. Our webservers have the URL /.well-known/acme-challenge/, used for ACME challenges, aliased somewhere else on the filesystem - To /tmp/challenges.

See the issue already?

Some *bleep* over at the Debian Package Maintainer group decided that Apache could save very sensitive data into /tmp, so, it would be for the best if they changed something that worked for decades, and enabled a SystemD service unit option "PrivateTmp" for the webserver, by default.

What it does is that, anytime a process started with this option enabled writes to /tmp/*, the call gets hijacked or something, and actually makes the write to a private /tmp/something/tmp/ directory, where something... Appeared as a completely random name, with the "apache2.service" glued at the end.

That was also the only reason why I managed fix this issue - On the umpteenth time of checking the directory structure, I noticed a "systemd-private-foobarbas-apache2.service-cookie42" directory there... That contained nothing but a "tmp" directory with 777 as its permission, owned by the process' user and group.

Overriding that unit file option finally fixed the issue completely.

I have just one question - Why? Why change something that worked for decades? I understand that, in case you save something into /tmp, it may be read by 3rd parties or programs, but I am of the opinion that, if you did that, its only and only your fault if you wrote sensitive data into the temporary directory.

And as far as I am aware, by default, Apache does not actually write anything even remotely sensitive into /tmp, so...

Why. WHY!
I wasted 4 hours of my life debugging this! Only to find out its just another SystemD-enabled "feature" now!

And as much as I love kidding on SystemD, this time, I see it more as a fault of the package maintainers, because... I found no default apache2/httpd service file in the apache repo mirror... So...

I actually never felt the need to scream at a co-worker so let's talk about that time a co-worker screamed at me instead.

tl;dr : some asshole boss screamed and threatened me because someone else's project was shit and didn't work.

Context: I was in my third year of school internship (graded) and my experience is C, C++, C#, Python all in systems programming, no web.

I was working as an intern for a shit company that was selling a shit software to hospitals (though not medically critical, thank God) the only tech guy on site was the DBA (cool guy) the product was maintained by a single dev in VB from his house, the dude never showed up to work (you'll understand why) and an other intern who couldn't dev shit.

I was working with the DBA on an software making statistical analysis from DB exports, worked nice, no problems here if we forget the lack of specs or boundaries (except must work in ieShit).

The other intern was working on something else (don't ask me what it is) I just remember it was in GWT before the community revived it. His webapp was requesting the company http server for a file instead of having one of it's java servlet to fetch it (both apps ran on sane server) which caused a lot of shit especially CORS error. That guy left (end of contract) and leaves his shit as is, boss asked me to deploy the app, I fiddle with it to see if it works and when I find out it doesn't then that asshole starts screaming at me in front of every other employee present, starts threatening to burn me in the tech world and have me thrown out of my school for no goddamn reason than the other dude's project doesn't work.

After the screaming I leave and warn my school immediately.

I guess that's why the other dev never came to work.

I had three weeks of internship left, that I did from home and worked probably less than 2 hours a day so suck it asshole.

Still had a good grade because I was reviewed by the DBA and he was happy with the work I did.

It was only later that I realized that what he did was categorizing as harassment (at least in France) and decided that never again this would happen without a response from my lawyer.

I explained last week in great detail to a new team member of a dev team (yeah hire or fire part 2) why it is an extremely bad idea to do proactive error handling somewhere down in the stack...

Example
Controller -> Business/Application Logic -> Infrastructure Layer

(shortened)

Now in the infrastructure layer we have a cache that caches an http rest call to another service.

One should not implement retry or some other proactive error handling down in the cache / infra stack, instead propagate the error to the upper layer(s) like application / business logic.
Let them decide what's the course of action, so ...
1) no error is swallowed
2) no unintended side effects like latency spikes / hickups due to retries or similar techniques happens
3) one can actually understand what the services do - behaviour should either be configured explicitly or passed down as a programmed choice from the upper layer... Not randomly implemented in some services.

The explanation was long and I thought ... Well let's call the recruit like the Gremlin he is... Gizmo got the message.

Today Gizmo presented a new solution.

The solution was to log and swallow all exceptions and just return null everywhere.

Yay... Gizmo. You won the Oscar for bad choices TM.

Thx for not asking whether that brain fart made any sense and wasting 5 days with implementing the worst of it all.

Hey guys, some of you might know this but for those who do not, there is an april fools HTTP error code which is 418, it's description is 'I\'m a teapot' #TheMoreYouKnow

(felt the need to escape sorry not sorry)

SO MAD. Hands are shaking after dealing with this awful API for too long. I just sent this to a contact at JP Morgan Chase.

-------------------
Hello [X],
1. I'm having absolutely no luck logging in to this account to check the Order Abstraction service settings. I was able to log in once earlier this morning, but ever since I've received this frustratingly vague "We are currently unable to complete your request" error message (attached). I even switched IP's via a VPN, and was able to get as far as entering the below Identification Code until I got the same message. Has this account been blocked? Password incorrect? What's the issue?

2. I've been researching the Order Abstraction API for hours as well, attempting to defuddle this gem of an API call response:

error=1&message=Authentication+failure....processing+stopped

NOWHERE in the documentation (last updated 14 months ago) is there any reference to this^^ error or any sort of standardized error-handling description whatsoever - unless you count the detailed error codes outlined for the Hosted Payment responses, which this Order Abstraction service completely ignores. Finally, the HTTP response status code from the Abstraction API is "200 OK", signaling that everything is fine and dandy, which is incorrect. The error message indicates there should be a 400-level status code response, such as 401 Unauthorized, 403 Forbidden or at least 400 Bad Request.

Frankly, I am extremely frustrated and tired of working with poorly documented, poorly designed and poorly maintained developer services which fail to follow basic methodology standardized decades ago. Error messages should be clear and descriptive, including HTTP status codes and a parseable response - preferably JSON or XML.
-----

This whole piece of garbage is junk. If you're big enough to own a bank, you're big enough to provide useful error messages to the developers kind enough to attempt to work with you.

all documentation points to an Invalid auth token being code 400 (ignore the fact that this is a code in the JSON response and not HTTP)

Me: here iz credential. Plz send datas
API: haha fock off and die mate, then credentials you got there aren’t workin’
API: code 998 invalid auth token
Me: *speechless* so that’s why it took me longer than it did to find that error, because YOUR CODE WAS MISSING ALL MY CHECKS FOR CODE 400.

Why can’t people design apis properly.

FUCK YOU FUCKING AZURE FUCKING FUNCTIONS:

EITHER LIMIT MY NUMBER OF TCP CONNECTIONS (before violently crashing)

or

FORCE ME TO USE THE GODDAMN PORT-PISSING, BARELY-MULTITHREAD-USABLE, SETTINGS-IGNORING EXCUSE OF A PATHETIC BUILT-IN HTTPCLIENT ON FUCKING CRACK (Seriously .net people fix that shit).

But not both... both are not okay!

If your azure function just moderately uses outgoing Http requests you will inevitably be fucked up by the dreaded connection exhaustion error. ESPECIALLY if using consumption plans.

I Swear, every day i am that much closer to permanently swearing off everything cloud based in favor of VM's (OH BUT THEN YOU HAVE TO MAINTAIN THE VM's BOO HOO, I HAVE TO BABYSIT THE GODDAMN CLOUD INFRASTRUCTURE AS WELL AT LEAST I CAN LOG IN TO A VM TO FIX SHIT, fuck that noise)

I am in my happy place today. At least I'm having great success diving into minecraft modding on the side, that shit is FUN!

Am I the only developer in existence who's ever dealt with Git on Windows? What a colossal train wreck.

1. Authentication. Since there is no ssh key/git url support on Windows, you have to retype your git credentials Every Stinking Time you push. I thought Git Credential Manager was supposed to save your credentials? And this was impossible over SSH (see below). The previous developer had used an http git URL with his username and password baked in for authentication. I thought that was a horrific idea so I eventually figured out how to use a Bitbucket App password.

2. Permissions errors
In order to commit and push updates, I have to run Git for Windows as Administrator.

3. No SSH for easy git access
Here's where I confess that this is a Windows Server machine running as some form of production. Please don't slaughter me! I am not the server admin.
So, I convinced the server guy to find and install some sort of ssh service for Windows just for the off times we have to make a hot fix in production. (Don't ask, but more common than it should be.)
Sadly, this ssh access is totally useless as the git colors are all messed up, the line wrap length and window size are just weird (seems about 60 characters wide by 25 lines tall) and worse of all I can't commit/push in git via ssh because Permissions. Extremely aggravating.

4. Git on Windows hangs open and locks the index file
Finally, we manage to have Git for Windows hang quite frequently and lock the git index file, meaning that we can't do anything in git (commit, push, pull) without manually quitting these processes from task manager, then browsing to the directory and deleting the .git/index.lock file.

Putting this all together, here's the process for a pull on this production server:
Launch a VNC session to the server. Close multiple popups from different services. Ask Windows to please not "restart to install updates". Launch git for Windows. Run a git pull. If the commits to be pulled involve deleting files, the pull will fail with a permissions error. Realize you forgot to launch as Administrator. Depending on how many files were deleted in the last update, you may need to quit the application and force close the process rather than answer "n" for every "would you like to try again?" file. Relaunch Git as Administrator. Run Git pull. Finally everything works.

At this point, I'd be grateful for any tips, appreciate any sympathy, and understand any hatred. Windows Server is bad. Git on Windows is bad.

I used to be a sysadmin and to some extent I still am. But I absolutely fucking hated the software I had to work with, despite server software having a focus on stability and rigid testing instead of new features *cough* bugs.

After ranting about the "do I really have to do everything myself?!" for long enough, I went ahead and did it. Problem is, the list of stuff to do is years upon years long. Off the top of my head, there's this Android application called DAVx5. It's a CalDAV / CardDAV client. Both of those are extensions to WebDAV which in turn is an extension of HTTP. Should be simple enough. Should be! I paid for that godforsaken piece of software, but don't you dare to delete a calendar entry. Don't you dare to update it in one place and expect it to push that change to another device. And despite "server errors" (the client is fucked, face it you piece of trash app!), just keep on trying, trying and trying some more. Error handling be damned! Notifications be damned! One week that piece of shit lasted for, on 2 Android phones. The Radicale server, that's still running. Both phones however are now out of sync and both of them are complaining about "400 I fucked up my request".

Now that is just a simple example. CalDAV and CardDAV are not complicated protocols. In fact you'd be surprised how easy most protocols are. SMTP email? That's 4 commands and spammers still fuck it up. HTTP GET? That's just 1 command. You may have to do it a few times over to request all the JavaScript shit, but still. None of this is hard. Why do people still keep fucking it up? Is reading a fucking RFC when you're implementing a goddamn protocol so damn hard? Correctness be damned, just like the memory? If you're one of those people, kill yourself.

So yeah. I started writing my own implementations out of pure spite. Because I hated the industry so fucking much. And surprisingly, my software does tend to be lightweight and usually reasonably stable. I wonder why! Maybe it's because I care. Maybe people should care more often about their trade, rather than those filthy 6 figures. There's a reason why you're being paid that much. Writing a steaming pile of dogshit shouldn't be one of them.

Everytime I am developing an API (from scratch, not when extending an old one) I try to return 418 HTTP error code in places that aren't yet developed or mainly when something that shouldn't have happened did actually happened. (example: failed non-essential assert, yes python)

So it's always lighter on lungs seeing people running around with wtf.png faces when their browser says "I AM A TEAPOT".

I can't talk to our management. It's not like they aren't present nor that I wouldn't find them. I'm infront of their office actually.

But apparently their room number of 505 suggests that they don't support a modern protocol version and I disabled my legacy support. This won't work.

*laughing maniacally*

Okidoky you lil fucker where you've been hiding...

*streaming tcpdump via SSH to other box, feeding tshark with input filters*

Finally finding a request with an ominous dissector warning about headers...

Not finding anything with silversearcher / ag in the project...

*getting even more pissed causr I've been looking for lil fucker since 2 days*

*generating possible splits of the header name, piping to silversearcher*

*I/O looks like clusterfuck*

Common, it are just dozen gigabytes of text, don't choke just because you have to suck on all the sucking projects this company owns... Don't drown now, lil bukkake princess.

*half an hour later*

Oh... Interesting. Bukkake princess survived and even spilled the tea.

Someone was trying to be overly "eager" to avoid magic numbers...

They concatenated a header name out of several const vars which stem from a static class with like... 300? 400? vars of which I can make no fucking sense at all.

Class literally looks like the most braindamaged thing one could imagine.

And yes... Coming back to the network error I'm debugging since 2 days as it is occuring at erratic intervals and noone knew of course why...

One of the devs changed the const value of one of the variables to have UTF 8 characters. For "cleaner meaning".

Sometimes I just want to electrocute people ...

The reason this didn't pop up all the time was because the test system triggered one call with the header - whenever said dev pushed changes...

And yeah. Test failures can be ignored.
Why bother? Just continue meddling in shit.

I'm glad for the dev that I'm in home office... :@

TLDR: Dev changed const value without thinking, ignoring test failures and I had the fun of debunking for 2 days a mysterious HAProxy failure due to HTTP header validation...

tldr: my classmates suck and I hate them
We study cs in school, and my classmates are super dumb.
Here is an example from today:
The task: build an http server in python, using sockets.

My classmates: writes everything in the main function, uses try-expect for everything and every error possible, nothing works, nothing worked after a week.
Me: properly separated to different functions, used goddam regrx to get data from requests, used asyncio to make sure it can handle multiple requests at the same time, everything worked after 2 hours.

But, and here is the problem, after I finish they ask me a bunch of dumb, 'Just Google it dude' questions and they call me condescending because I get mad after the second hour of teaching them the same thing.
Once they told me:"you think you are a better programmer then us" and I just want to say this out loud: I AM A BETTER PROGRAMMER THEN THEM, THEY ARE THE PERFECT EXAMPLE OF HOW YOU SHOULDN'T DO ANYTHING AND I HATE THEM.
That's it, I'm done. I feel much better now.
PS: it's okay to suck at programming, but please stop thinking that everyone who's better than you is condescending.

What the FUCK im fixing integrations on some dumbass's API. Biz wants this in prod on monday. It's fucking saturday. Anyway

Me: why did you give us a 200 even if its an error
Them: thats normal
Me: If it's an error it shouldnt be 200
Them: its a 200 because the api params are correct but differ in value so its not an http error but an api error

lmao

The moment you realize that you have successfully beaten reality with your unit-tests...

There are unit-tests for ...
... the api returning a 408 Http StatusCode when an internal request times out.
... the react app take this status-code and fires an action to display a specific error message for the user.

Every bit of code runs just fine.

Deploy this hell of an app on the server. Dandy Doodle.

Do a smoketest of the new feature.
FAIL!
Chrome starts to crumble during runtime. The api Request freezes.
Firefox takes the 408 api response but fails to interpret it in react app.

So I began to wonder, what the hell is going on.

Actually I recognized that I had the glorious idea to return a clientside error code in a serverside api response.
Glorious stupidity :/

Finally I fixed the whole thingy by returning an 504 (Gateway timeout) instead of 408 (Clientside timeout)

Cheers!

The website I'm working on went down because of a 500 HTTP error and halted my company of working

I should not code in production

So I just spent 2 hours debugging a script that fetches data from an API. Thats all it was supposed to do. Http get some data.

It wasnt working and was giving a "parse error". Worked fine in browser.

So it turns out it was using http 0.9 (first documented http version, defined in 1991) and wasnt sending any headers. And js cant do no headers...

So yea I now have to write a tcp / http 0.9 client in js

With a recent HAProxy update on our reverse proxy VM I decided to enable http/2, disable TLS 1.0 and drop support for non forward-secrecy ciphers.

Tested our sites in Chrome and Firefox, all was well, went to bed.

Next morning a medium-critical havock went loose. Our ERP system couldn't create tickets in our ticket system anymore, the ticket systems Outlook AddIn refused to connect, the mobile app we use to access our anti-spam appliance wouldn't connect although our internal blackboard app still connected over the same load balancer without any issues.

So i declared a 10min maintenance window and disabled HTTP/2, thinking that this was the culprit.

Nope. No dice.
Okay, i thought, enable TLS 1.0 again.

Suddenly the ticket system related stuff starts to work again.

So since both the ERP system and the AddIn run on .NET i dug through the .NET documentation and found out that for some fucking reason even in the newest .NET framework version (4.7.2) you have to explicitly enable TLS 1.1 and 1.2 or else you just get a 'socket reset' error. Why the fuck?!

Okay, now that i had the ticket system out of the way i enabled HTTP/2 and verified that everything still works.

It did, nice.

The anti-spam appliance app still did not work however, so i enabled one non-pfs cipher in the OpenSSL config and tested the app.

Behold, it worked.

I'm currently creating a ticket with them asking politely why the fuck their app has pfs-ciphers disabled.

And I thought disabling DEPRECEATED tech wouldn't be an issue... Wrong...

So there I am sitting in front of my laptop, and trying to npm i and I am getting all sorts of sha mismatch errors.

After lot of debug I conclude it is coming from the proxy as it refuses to download and supplies the error page.

It says it's because I'm using the old proxy so they give me the new URL which I set up and it works.

All good until my password expires. I use our bash script to change it. NPM is buggered again throwing the same errors.

Go to IT, tell them the saga begins.

After a countless hours of looking at the log files we notice that the npm registry is set to http instead of the standard https (thanks bash script). so our firewall blocks the download.

Sorted, finally.

Almost. NPM now works fine, but when I go and I play around with node and axios, I get my requests time out. My instinct says its the bloody proxy again.

So I hit up my trusted WIN Support guy and he confirms that the url is not blocked. So he starts monitoring whats going on and turns out, every time I run the node app, node casually ignores the system-wide proxy settings and tries to send the request as the PC rather then my username.

Since the pc's don't have rights on the proxy it is being refused...

Thank fuck for the corporate proxies, without them, I could just develop things not ever learning these quirks of node...

So, today a developer from a web app consuming our services requested to fix a 429 http error code (too many requests) they are seeing. The request is on an email with our managers cc'ed

How the fuck is Firebase still a thing? I just spent hours debugging a random "not authorised" error, only to find out you need to enable a deprecated API even if you're only using the new (recommended) one. Do they tell you about it? Fuck no, they keep it disabled by default, they tell you to only use the new API, and they make it pretty much impossible to find the deprecated API you need to enable without a direct link.

And why the fuck does the official SDK send image URL as { "imageUrl": "http://..." }, when the endpoint expects it to be { "image": "http://..." }? Why the fuck does the documentation mention both options interchangeably, while only the latter one actually works?

SIM 800L
The fucking nail to my coffin. This thing is so unreliable. I fixed on issue get the next one. Then get an error trying to make a http request, with little information on the web. Eventually switch to FTP which is working for a while. Then suddenly nothing is working properly. Even the serial communication has errors. This process took over 6 months. Constant debugging and headscraching involved. After hundreds of hours I give up. I'm going to switch to a Raspberry Pi Zero with an UMTS Stick attached. This is going to cost way more battery time but my project needs to be finished by july and I'm tired of this shitty little module.

Someone wrote some error handling middleware for the whole application.
Then someone wrote some default classes for HTTP errors; BadRequest, Unauthorized and so on.

If I didn't know any better, I'd think throwing one of these default errors would give the proper status code, instead of default everything to 500.

But alas, I do know better.

I am trying to implement an API. It has a very good documentation, everything is written clear and simple, along with

- HTTP 401 on unauthorized request and
- Error codes from 1-35 with definitions

Opened the provided sample file, changed the username, password and client code fields to our own in the source, then tried the request. The Response:

HTTP 200
{"ErrorCode":-1,"ErrorDescription":"Unauthorized."}

Well, thank you very much! 🤬

I once had to write a feature, which should allow the user to login and edit an appointment, which was automatically set. All the data we got, came from an incredibly unreliable API. And with incredible unreliable I mean like heisenbug-level unreliable.
The API spoke perfectly unreadable xml and was a horror to work with.

After a few weeks of me being messed with by this shit piece of an API, I finally got something which did kind of work sometimes.
Proper error handling has been added later and just before I was done, fixing all the flaws of their data management and nonsense status codes (not http status codes) which rarely correlated in at least some way with their data, our client said "scrap this, we don't want it anymore"

Many hours and effort gone, this thing worked almost perfectly.

One of the most headache-inducing things about being a developer is having to find a solution to every little ailment that software has.

An example would be: working with a particular stack. LEAN, MEAN, LAMP, WAMP,.. The nightmare of having to deal with every single error in PHP, NodeJS, Apache Server, Nginx, the HTTP spec intricacies, the HTML5 spec, API problems..

Sometimes it's just a lot to deal with and I'm trying not to lose my patience.

Fucking retard Liferay.....

At least 2 users (one inour team and another at client's) are claiming they've successfully opened a portlet view multiple times at day X. And a month later it stopped working.

I open up Liferay's (tomcat's) localhost_access.log and can see all the portlet requests at day X have returned http:400

Normally I would consider the human factor and rule this as a human error, assuming they were connected to another environment, another server, etc. But since this is The Fucking Liferay - I'm not that fast in trusting even logs :(

Who the fuck made this piece of shit....

I'm currently migrating one of the companies services from technology A to an B based solution...
Today I had to remotly troubleshoot an error occuring somewhere on our client's backend application, that wans't enabling us to register any given webhook to our endpoints...
We finally gave in and looked up the data packets using a sniffer only to find that the only difference was that in the A technology project our staff ended up returning a Status Code plus the respective Reason Phrase, in our newest version we only send the HTTP Status Code... Guess who wasn't aware of HTTP 1.1 RFC consideres the Reason Phrase optional and an unecessary overhead??? God dammit... In simple terms...

I am the responsible for the atlassian Suite at work, as I maintain the systems, set them up, and stuff.

One day, our crowd (the authentication and authorization application) just went crazy. At like lunch time it could not connect to the AD anymore. No reasons. Throwing XSRF errors (cross site scripting), because http would connect to https. "won't do it, fuck you" it told me. Out of the blue. Noone changed anything. And yea, seriously. Noone did.
It just refused to connect (as connecting to AD is connecting yourself with you own api. And refusing yourself talking to yourself). It runs behind a proxy. Therefore http/https. Well, this worked for years. But out of sudden not anymore.

Yea. Fuck you.

It was reported some hours later, at like 3pm, as people could not login to the applications using crowd as authentication and authorization server.

Tried to debug the system, where nothing was did, to make it work. At best time to fail.

First workaround: if you are logged into one of the other applications of atlassian, just refresh the site, so your SSO token gets a refresh and you are signed on again.

Then I searched more and more. And more.
But nothing worked, nothing helped.

So I addressed an emergency maintenance, take down the whole Suite, restart crowd, to apply some changes to it's settings, not knowing what happening then, because all connections of SSO will then be released. Sent out the mail like 30 minutes beforehands.

While waiting for the window, I just typed my credentials... And redid, and redid, so to type and being bored.
Three minutes before the window...

It just worked again.

Well. Wtf. Serioudl
Just came back.

No Intrusion, no changes at all. Just came back, as nothing has happened.

Kind of best part of this story... A headhunter messaged me on my way home to offer me a job as an Atlassian Suite SysAdmin for a company, at kinda the double of my salary.

At first I was thinking to go there, and when someone then asked me sth about Atlassian just start to laugh and then leave still laughing...

But then I very nicely respond that I dont want to cry at work. And wished him best luck.

I am doing some bad upgrades now on our Suite. Very painful.
And I looked into the start scripts. Some Look like the untalented intern tells another one to write scripts. Seriously wtf.

Today I followed the guide to Update a confluence and change database to Postgres. Didnt work, Postgres error.
Try it again, jquery won't load. Next try, tomcat not starting anymore. Did same thing. Every fucking time.

Yea. Maintenance window to get a nice new export soon. Will only take an hour.

To switch database in confluence, you need to set it up very fresh. And then Import your export.
Export takes an hour at our system.
Importing maybe the same time. Hope it will work (hint: Nope).

Oh, can be nice also. Just tell the Bitbucket to migrate databases, there is a fucking setting for it. Enter new database, ready, go, finished.

At least they don't raise costs very much every kinda year.
Oh sorry, yes, they do.

Why the response to a SOAP request is a HTTP error?

It took me half an hour to find the reason of an empty response.

Me: *ask well detailed questions around Ruby on Rails and responses in JSON that won't fucking work because I don't know how to make it work my way*
Someone : *Answers*
Me: *tests the solution. Nothing works, his ruby syntax is from 1995, and it doesn't help me
Me: "Sorry but there's a syntax error in your answer, I don't know how to make your answer work. Plus, how should I edit my json.jbuilder file with your answer?
Dude: " I am not a RoR developer by trade, I just know how HTTP works :)"

WE ARE BOTH FUCKING LOOSING TIME HERE YOU FUCKING MORON

Same dude: " I don't see any of that in your code and I'm not sure what you want to edit? Seems to me like you don't really need to, but I'm not sure"

YOU ARE NOT A FUCKING ROR DEVELOPER, YOU SAID IT YOURSELF, SO WHY DO YOU KEEP BOTHERING?

(n.b. : I litteraly pasted his two last answer. Didn't edit anything)

It's 2022 and web browsers are still unable to unfollow redirects.

If I open some URL in a new tab and it redirects me to /503.html or similar due to some server errors (which is bad design to begin with), there is no way to see which URL was redirected from. The "back" (←) navigation button is greyed out, so there is nowhere to go back to.

One might open a new tab to look at it later without realizing it redirected to an error page. Then one opens it, sees /503.html, and has forgotten which article one was going to read.

Only on the mobile edition of Chrome/Chromium, switching between desktop and mobile view unfollows the redirect. But on Firefox mobile, Chrome/Chromium-based desktop, and Firefox desktop, there is no way to know which URL redirected me there.

STOP sending HTTP 200 with the error on the body for crying out loud!!!

I think I've figured out why
http:200 ERROR
Is sometimes returned from some APIs... Sort of legit

Phillip Hallam-Baker and Roy Fielding misspelled "referer" in the HTTP specification. Are there any other misspellings in core/popular libraries that you know of?

When the API returns 500...

I'm not sure who the fuck implemented the error handling of spring boot but goddamn he/she needs to be fired. Why the fuck does the application return a weird error about a setting not being set when it can't connect to a database?? Wtf took an hour to solve and that's not the only thing I hate about spring boot. Why is the documention utter garbage, why do I have to rely on tutorials and can't I just read in the documentation how for example the http rest mapping works. Now I have to cross-reference multiple tutorials to find the best way because guess what there are multiple ways to do something in this framework and some tutorials don't even work.

If your code is giving HTTP 500 error on a production server, go kill yourself, until you are having a development environment on the production server. In that case, kill your manager! 💢

I tried Appgyver over christmas, since it promised easy front-end (no-)coding I was looking forward to getting rudimentary frontends done faster.
Well, the first real project that I wanted to start didn't compile anymore (internal error from the service), the page told me to reload and try again.
It failed again... And again.
Fine with me, I only spent 10 minutes on the project at this point.

I then searched for the bugreporting page and found it. The sad thing is that when I wanted to open a ticket the server crashed. It didn't even return a HTTP error, just a JSON saying there is a error and a GUID.

I have to say, if a Dev decided to have holidays without new issues that's one way of getting that done.