431 Request Header Fields Too Large at Login

[J-Light]

📦 Platform

Self hosting Docker

📦 Deploymenet mode

server db(lobe-chat-database image)

📌 Version

v1.79.10

💻 Operating System

Windows

🌐 Browser

Chrome

🐛 Bug Description

We are using AzureAD to provide SSO for our users. Out of approximately 50 users, 2 are experiencing difficulties logging in. This difference has been difficult to track down.

After a successful login and redirect to /chat, the affected users see the following message:

Using developer tools, I see a "431 Request Header Fields Too Large" error. The proxy access log shows:

172.19.125.159 - - [16/Apr/2025:07:06:08 +0000] "GET /en-US__0__dark/chat HTTP/1.1" 431 0 "-" "-" 212  "http://172.17.125.159:3210" 0ms
172.20.1.254 - - [16/Apr/2025:07:06:08 +0000] "GET /chat HTTP/2.0" 431 0 "-" "-" 211 "http://172.17.125.159:3210" 49ms

Initially, I suspected the proxy, but the total payload is only tens of KB—well below the proxy's header size limits. The access logs indicate that the application itself is issuing the 431 error.

Can you advise on possible causes for this issue and suggest how I can resolve it?

📷 Recurrence Steps

This issue is inconsistent to reproduce: 48 users do not have any problems, while 2 users experience the issue consistently.

🚦 Expected Behavior

Login should be error with a 431 error.

📝 Additional Information

Looking at the cookies for both working and affected users, I’ve noticed a difference. For users who are unable to log in, the authjs session token is split across four key-value pairs with the following keys:

__Secure-authjs.session-token.0
__Secure-authjs.session-token.1
__Secure-authjs.session-token.2
__Secure-authjs.session-token.3

All other users have a single key-value pair:

__Secure-authjs.session-token

This may be contributing to the issue.

[lobehubbot]

👀 @J-Light

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.
非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[arvinxx]

more likely your use large content?

[J-Light]

Hi @arvinxx , sorry I did not follow of what you meant as large content.

The error happens as soon as the token redirect. Any payload at this point is only from the SSO provider.

[J-Light]

After further investigation, it seems the only noticeable difference between the affected users and others is the size of their profile pictures. Is it possible that the application is attempting to cache the users' profile pictures within the encrypted cookie? I have tried removing the affected users’ profile pictures, but I’m unsure if there are additional steps required to clear any cached data or storage related to the user profile, as using a Private Browsing session does not seem to reduce the token size.

Any guidance on where to clear or reset user-specific cache in the application would be appreciated.