It was a normal day for me, checking on the PRs and looking at the Errbit channel when my technical support colleague buzzed me and said

Morning Hanna. “XXX” complaint that they are not able to login to the “YYY” portal. When I gone through the errbit channel I found this error.
https://errbit.xxxx.com/apps/xxxx/problems/xxxxx

Could you please check on this? Thank you.

I initially thought it was just a caching issue or something related to the mobile view since he mentioned he was logging in via mobile. But when I tried to log in on his behalf from my device, I could access it just fine. So, it must be his device, I guessed. After he had cleared his cache and cookies several times and not just him, but his colleague couldn’t log in either, panic started setting in (because this is our premium client, haha).

And of course, this is my first time dealing with Remix, which have significance different with pure React in term of handling sessions etc

The troubleshooting began. Firstly, I checked the server log. Strangely, it managed to go through the signing process, meaning if I entered the wrong password, it managed to get a response back from the server, so this was not a blocking issue or something related to my auto-login function for certain users.

Then, I rechecked the logs. It managed to create the session for the user, but somehow it returned a 502 Bad Gateway, meaning it failed to execute the method afterward. Hmm… I then tested login using different credentials and roles, and looked into the database. For your information, the backend will send the entire user’s object back to the frontend, which is quite large, plus the JWT token.

After comparing various elements, and since I do not have access to the remote server, I solely relied on my console.log, debugging what might be going wrong. Suddenly, near midnight, my DevOps posted this on Teams:

[Wednesday 11:35 pm] XXX

their header size is big….

[Wednesday 11:36 pm] XXX

2024/05/08 15:20:13 [error] 4110#4110: *477 upstream sent too big header while reading response header from upstream, client: xx.x.x.xxx, server: , request: “POST /login?_data=routes%2Flogin HTTP/1.1”, upstream: “http://xxxxxx/login?_data=routes%2Flogin”, host: “xxxx.com”, referrer: “https://xxxxx/login”

Yes, that might be an answer to the 502 Timeout Gateway error that I saw in the console.

The error message suggests that the issue is with the size of the headers being sent back from the upstream server to NGINX, which then tries to relay these to the client. This situation is related to the buffer settings for response headers, not the client request headers. So that makes the difference. What we need to do is to:

1. Adjust the proxy_buffer_size and proxy_buffers parameters

• proxy_buffer_size: Determines the size of the buffer used for headers in the response from the upstream server. If this is not large enough to accommodate all the headers from the upstream, NGINX will throw the error that I’m facing

The settings:

proxy_buffer_size 256k; 
proxy_buffers 4 512k // Increases the overall buffering capacity for responses

Finally, after testing and resizing the header, using the testing username with a large object, I managed to log in. However, I’m finding ways to place a preloader for JavaScript loads for the first time login. Initially, it was slow loading after sign in, but then it loads faster afterwards. Fooh, am I so relieved!