Third party configuration change left us puzzled

Author:
Updated on: January 15, 2022 · 5 mins read
Categories: nodejs   | request-headers   | javascript |

Debugging is one of the most important and frustrating parts of the software engineer’s day and debugging the code on which you have never worked on is even harder.

Third party configuration change left us puzzled
A similar incident happened this week when a service that my team has not touched since the last six months started breaking. I was given the opportunity to figure out the reason behind the issue.

Prologue

1. Prologue
2. What started happening?
3. What we did?
4. Postman issue with Accept-Encoding header
5. The RCA
6. Sample Nodejs app
7. What is this all about?
Let’s first discuss a little background on what this service did. All this very simple application did was to call a third-party service with whatever data that frontend has provided us along with some of the tokens that used to sit in the backend system. Finally, it would send back the data to the frontend.

What started happening?

Suddenly on a Monday morning, we started receiving random unreadable strings from the third-party APIs. Something like this.

�H����/�IQ�)
And since frontend was not able to parse the data, it started breaking for all live users.

What we did?

The first thing that we did was to create a similar postman request. To my surprise when we tried to hit that API on postman, we were getting the correct response. Since we are using Node’s default http library, we took a copy of it from the postman and tried it in local.

Postman request code
Same result again.🤯

Finally we logged the whole request on the server for a user. The only difference was with headers that we were sending to the third-party.

As soon as we copied over the headers to our local, it started giving the same unparsable response.

The next step was fairly simple, to figure out which header was causing the issue.

Soon we realized that the issue was with the Accept-Encoding header. As soon we found it, I went ahead and removed the header from the request and everything started working fine.

Postman issue with Accept-Encoding header

When I added this header to the same postman request, it was still giving the correct response. I am still not sure what was the main reason behind it. I believe there might be a setting or config level change that we can do in postman which will allow us to show the gzip response as it is.

If anyone from you know this, please post in the comments.

The RCA

So, apparently, the third-party system made some changes and started providing gzip response if anyone was requesting it and since this header was already set in our system, it started giving a compressed response.

And our frontend system was not well-versed to handle this, everything started breaking.

Sample Nodejs app

I created a sample Nodejs backend that can help us understand this better and made a few requests to verify the hypothesis. Here I am trying to compress the response and send the compressed response if someone is requesting for it.

var express = require("express");
var app = express();
var compression = require('compression'); // this
app.use(express.logger());
app.use(express.compress()); // this
app.use(compression());

app.get('/', function(request, response) {
  response.send('Hello World!');
});

var port = process.env.PORT || 5000;

app.listen(port, function() {
  console.log("Listening on " + port);
});
Just run the server and try executing this curl in local.

curl --location --request GET 'http://localhost:5000/' \
--header 'Accept-Encoding: gzip'
Now try the same thing in postman. Both will give a different response, given you are using the same default config as I am.

The major part about which we should worry about is:

var compression = require('compression');
app.use(express.compress());
This makes sure, if the correct header is set, correct response is passed to the requestee.

What is this all about?

Better explained wrote a great article on what these headers are all about.

But to shed a little light on this, this was introduced so that the backend can send the encoded files to frontend reducing the overall size Thus making the websites loading faster.

This was done on the basis of a header and it was the responsibility of frontend if they can parse the gzip response or not.

If the browser/frontend can parse the zgip, they will just send Accept-Encoding header. If the backend receives this header it will just send the response in gzip format.

One way to identify this is by looking at the response headers. You will find the Content-Encoding header in the response with the value of gzip in this particular case.

There are other encoding formats as well. Better explaned article will give more clarity on that.

That’s all for today. Please share it on Twitter if you found it useful.

You May Also Enjoy

1. Faster validation of request parameters using middleware in node.js
2. How to become Node.js developer | Coming back from OOP background
Please share your Feedback:

Did you enjoy reading or think it can be improved? Don’t forget to leave your thoughts in the comments section below! If you liked this article, please share it with your friends, and read a few more!

We don't share your details with others