Hi! I want to share the details of a potential “bug” in the dashboard area, specifically the login page. I encountered this bug before, but I thought it was only temporary. It’s been 3 months already, yet the problem still persists.
Click the “[Login]” button located in the upper-right corner of the header section.
Log in by entering user credentials in the login form.
Voilà! The error will appear.
Limitations
The error will only appear if you enter the login page using the linkfrom the forum (i.e., https://forum.infinityfree.com/). It does not appear when you:
Visit the login page directly in the browser.
Enter the login page through the link located on the homepage.
Once the error appeared, the next subsequent attempts would succeed. That means only the first login attempt will result in an error.
I am glad that I have my own password manager, which automatically types out the login credentials on the login form. That’s why I do not have to worry when I need to re-authenticate each time the error appears. But how about others? Although visiting the forum page before authenticating is uncommon for most users, some of them will probably think that the dashboard is no longer available.
So what could be the reason for the error?
EDIT: You, the reader, should participate in the discussion if you’ve experienced the same bug as mine. The main goal of this post is to figure out the exact cause of error. Don’t be afraid.
You are not the first one to discover this — I’ve also discovered it before.
Unfortunately I was unable to locate my post back then; basically, the Admin says that he suspected the issue was being some header size limit, and he had already increased that — yet somehow the issue persisted. Which translate into “a stubborn bug”.
I’m aware the issue exists, especially when logging in through the forum. But I’m not entirely sure why this error appears. I have not been able to reliably reproduce it. It doesn’t happen in a fresh browser for me.
I suspect it’s related to the browser being stuffed with too many cookies which one of the many load balancers and routers in the path between you and the client area doesn’t like. But when I cannot reproduce the issue, I can’t really find out where this issue is coming from.
This issue is something that seems to be reproduced in low-memory devices, at least it seems like it for me.
On my MacBook, this issue never appears. (Air, 128GB, 8GB ram, ~1.3GB used by Chrome)
On my HMD Vibe, this issue appears the same way as described (HMD Vibe 64GB, since there are 2 variants. 4GB ram, ~2.7GB used by Phone.)
On my UbuntuBook, this issue is a once-in-a-while thing. It appears most when heavy-ram programs are running. (Acer c720, 16GB, 4GB ram with 2GB swap, ~0.2GB used by wayland)
What do you mean exactly, @Admin? I don’t think it is related to browsers at all. I got successful replication of the bug on various browsers with fresh/new browser profiles and dedicated private windows for testing purposes.
I think it’s related to origin server, and not the other way around. As far as I know and according to this article, “Bad Gateway” error (with error code 502) usually happens when Cloudflare fails to communicate with the origin/host server.
I’ve read a few sources online that some of the origin/host servers would fail silently if the size of the cookies from Cloudflare exceeds beyond the size limit of the cookies imposed by the original/host servers. Although I am not sure if this is applicable for this case as the evidence correlates it with the 520 error code instead of the 502 error code.
Is there anything you can do to figure out where the issue is coming from? How about an inspection and a thorough investigation of various logs, reports, and statistics from the Cloudflare dashboard?
Is there anything we can do to diagnose the problem on our own? Some of us could reproduce/replicate the problem.
My machine also has the same RAM capacity. However, it’s hard to figure out how RAM capacity and usage is connected to the bug. As far as I know, the "Bad Gateway Error is beyond the client-side’s control.
If that’s the case, then @Jri-Creator might be incorrect. The correlation is not enough to justify the causation.
Yes, 5xx are server errors, however that does not mean the server is at fault. It just indicates that is where the error occurred (usually, it can be manipulated, but usually).
5xx error can occur when browsers send information the server is not expecting (too many / too few cookies, incorrect headers, data, etc). The server responds 5xx as it can’t process it, but the actual error stems from the browser.
Unfortunately CF does not have the most useful logs for events like this, unless it’s hidden and I haven’t found it yet, it’s not possible to get a full snapshot of headers and such every time a 5xx is reported.
I’m pretty sure that it’s a problem with headers being too big, and those headers being too big because of cookies. Cookies are also sent as part of the request headers, so too much cookie data can result in a header getting too big.
That’s not a problem in or with the browser. However, request headers are sent by the browser, and if the server has a problem with that, then the browser is still the thing that triggers the error.
It’s strange though that the issue keeps happening to you but I cannot for the life of me reproduce it.
UPDATE: I think I found the difference. I can reproduce it if I enable “Remember Me”. Without that box, it does work. That’s great, because now I can actually test something.
Enabling Remember Me results in an additional cookie being set by the server to handle the actual remembering. It’s very likely that this is what pushed the header size over the limit.
I am glad that the exact cause of error has been identified now. I tried to reproduce the error with the same steps. Apparently, it looks like the bug has been fixed, too. That’s great! Thank you, @Admin!
