Header fields are too long

[glaucon1984]

Since the last 1.1.2 update when I try to access the device over a reverse proxy (so I can open it over public internet) I get the message:
"Header fields are too long"

I've configured SWAG (Nginx) with 16K buffers:

# `nginx.conf`

http {
  large_client_header_buffers 4 16k;
}

All the other sites I'm publishing over this proxy are working fine, as Aura was before the update.

Tested in my Android phone (Vivaldi browser) and Chrome/Edge on a Windows 11 PC.

Is this a bug or I need to increase the header size in my reverse proxy? If so, which size?

If I flash 1.1.1 it works perfectly fine over the reverse proxy again.

[21cncstudio]

Thanks, this looks like the new web backend in 1.1.2 being more strict about request header size when Aura is accessed through a reverse proxy.

For now, could you please try increasing the effective request-header limit on the Aura-facing proxy path to 4096 bytes and test again?

If it still fails, please try 8192 bytes and let me know whether that works.

This is not a tiny one-line fix on my side, so I need to think a bit about the safest way to handle it in firmware without risking regressions in the web stack.

[glaucon1984]

It was 16k, I've increased to 32k and still the same error.

# `nginx.conf`

http {
  large_client_header_buffers 8 32k;
}

[21cncstudio]

Thanks, that confirms this is on my side, not an Nginx buffer issue.

I’ll look at the safest way to fix it in firmware for reverse-proxy use without causing regressions elsewhere in the web stack.

[21cncstudio]

I’ve pushed a firmware-side fix for this and uploaded a new beta build to the existing v1.1.2 release:

project_aura_1.1.3-beta-00b7344_ota_firmware.bin

The change increases Aura’s HTTP request-header limit, which is the most likely cause when the device is accessed behind a reverse proxy adding forwarded/auth/cookie headers.

Could you please try this beta build through your reverse proxy and confirm whether the web UI works again?

[glaucon1984]

I'm still getting the same message: "Header fields are too long".

This happens in Windows with Edge, Chrome and Vivaldi, even in guest/incognito/private mode. Same on Android with Chrome and Vivaldi. I can reboot into Debian if you want me to test browsers there.

Strangely, Firefox and Floorp work fine in Windows, Firefox on Android works as well.

On iPhone, Safari works, MS Edge on iPhone shows the information but slightly scrambled and only text, I believe this uses the Safari engine, but this is my work phone, so I wouldn't pay attention to this edge (pun intended) case, I wouldn't be surprised if all the Zero productivity Trust BS my company puts in this phone is the cause of this.

So,

• Chromium-based not working in either Android or Windows clients
• Safari-based works in iPhone
• Firefox-based works in Android and Windows

[21cncstudio]

Thanks for the detailed breakdown — the Chrome vs Firefox split is a very useful clue.

The header limit is already set to 8 KB on my side, so Chrome must be sending significantly more than that through your proxy. The most likely culprit is a forward auth setup (Authelia, Authentik, Keycloak, etc.) injecting a large session token or Authorization header — those can easily reach 4–8 KB on their own, and Chrome picks them up while Firefox handles sessions differently.

Could you check what Chrome is actually sending? The quickest way is to open DevTools → Network → click any failed request → Headers tab, and look for anything large in the request headers — especially Cookie, Authorization, or anything starting with X- or Remote-.

Alternatively, if you have access to your nginx logs, adding $request_length to the access log format would show the total request size for each hit.

This will tell us the actual number we need to target rather than guessing.

[glaucon1984]

nginx logs:

$ docker exec swag grep " 431 " /config/log/nginx/access.log
[...]
192.168.88.1 - - [01/Apr/2026:23:01:59 +0100] "GET /favicon.ico HTTP/2.0" 431 26 "https://aura.******.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" "-" req_length=127
192.168.88.1 - - [01/Apr/2026:23:02:00 +0100] "GET / HTTP/2.0" 431 26 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" "-" req_length=20
192.168.88.1 - - [01/Apr/2026:23:02:00 +0100] "GET /favicon.ico HTTP/2.0" 431 26 "https://aura.******.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" "-" req_length=28
192.168.88.1 - - [01/Apr/2026:23:02:01 +0100] "GET / HTTP/2.0" 431 26 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" "-" req_length=20
192.168.88.1 - - [01/Apr/2026:23:02:01 +0100] "GET /favicon.ico HTTP/2.0" 431 26 "https://aura.******.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" "-" req_length=28

And Chrome DevTools:

I asked Claude and he suggested this:

Those http2_max values didn't help either.

[21cncstudio]

Thanks, this is much clearer now.

From your Chrome screenshot I can already see two important things:

• the 431 response is being generated by nginx itself (Server: nginx in the response headers), not directly by Aura
• the request includes an authelia_session cookie plus the usual Chromium Sec-CH-UA* / Sec-Fetch* headers

Together with the very small req_length values in the access log, this no longer looks like a simple “Aura backend header limit is too small” problem.

At this point, the most likely area is the Chromium + nginx + HTTP/2/auth path rather than Aura itself.

The two most useful next checks would be:

• look at the matching nginx error.log entries for those same 431 requests
• temporarily disable HTTP/2 for the Aura host/path and try the same Chromium browser again

If Chromium starts working over plain HTTP/1.1, that would strongly point to an nginx/HTTP/2 handling issue on the proxy side rather than Aura’s backend request limit.