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.

[glaucon1984]

Hi,
Sorry the delay, I've been quite busy. I tried with settings that would strip as much as possible from the headers:

location / {
    include /config/nginx/authelia-location.conf;
    include /config/nginx/resolver.conf;
    
    set $upstream_app 192.168.88.104;
    set $upstream_port 80;
    set $upstream_proto http;
    
    # Strip all proxy headers and add back only what Aura needs
    proxy_pass_request_headers off;
    
    # Only critical headers for basic functionality
    proxy_set_header Host $host;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Upgrade $http_upgrade;
    
    # Core proxy config only
    proxy_http_version 1.1;
    proxy_buffers 32 256k;
    proxy_buffer_size 256k;
    
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}

With this I can get the page to load but there is no info, just a "failed to fetch" message where the reading should go. It also prevents Authelia from working if I don't have the cookie in place (a guest session, for example).

I also tried to increase CONFIG_HTTPD_MAX_REQ_HDR_LEN to 12k and 14k (16k will break Firefox and local IP), but nothing, it still says "Header fields are too long".

I suspect the Chromium-based headers will simply not fit, so either I use Firefox or remove Authelia, and I'm not going to put this online without any protection, I don't want random people on the internet uploading random firmware to it.

[21cncstudio]

I dug into this further and found that the previous beta was likely not actually built with the increased header limit because of a build-config path issue on my side.

I have now prepared a new beta OTA build where the header-limit change is actually applied and verified in CI.

Please download the project_aura-ota-firmware artifact from this workflow run:

https://github.com/21cncstudio/project_aura/actions/runs/24280316334

This beta is based on commit f3f6f68 and is an OTA-only update, so no full flash or LittleFS update should be needed.

After downloading the artifact zip, extract the OTA firmware .bin and install it via Aura's OTA update flow. If this fixes the reverse-proxy/Chromium issue, I’ll turn it into a proper release-side fix instead of leaving it as a beta path.

If you cannot access the artifact from the Actions page, let me know and I’ll publish the beta binary another way.

[glaucon1984]

I flashed the 315KB file with the web interface and it crashed my device, it doesn't boot. I applied it over 1.1.3. I tried twice.

I also tried to compile your branch "http-header-limit-sdkconfig" but looks like Platformio is not happy, I could compile v1.1.3 without issues but this one was very hard to get going, after lots of "Updating metadata for the vscode IDE" and "Reading CMake configuration" I managed to generate the same 315KB firmware.bin (not the usual 3.6MB one).

Still nothing, black screen on the device and time out on the web console.

EDIT3: I've deleted the last comment, the issue was the cable, I've soldered it again and it now the screen doesn't go off.

[21cncstudio]

Thanks, and you are right about the beta build.

That 315KB image is not a valid/reliable Aura firmware build, so I am withdrawing it. I was able to get this header-limit branch to build on my side only with a custom library setup, but the build path is currently unstable and not reproducible enough for me to hand out test binaries with confidence.

Because of that, I am not going to ask you to try any more experimental builds for this issue at the moment.

Also, since you found and fixed the cable problem, that explains the black-screen behavior separately, so I do not want to mix that hardware issue with the reverse-proxy/header-limit investigation.

For now I am putting this on hold until I have a clean and reproducible way to generate a proper firmware image.