Skip to content

431 Request Header Fields Too Large at Login #7435

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
J-Light opened this issue Apr 16, 2025 · 3 comments
Open

431 Request Header Fields Too Large at Login #7435

J-Light opened this issue Apr 16, 2025 · 3 comments
Labels
🐛 Bug Something isn't working | 缺陷 unconfirm 未被维护者确认的问题

Comments

@J-Light
Copy link

J-Light commented Apr 16, 2025

📦 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:

Image

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.

@J-Light J-Light added the unconfirm 未被维护者确认的问题 label Apr 16, 2025
@lobehubbot
Copy link
Member

👀 @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。我们会尽快调查此事,并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

@dosubot dosubot bot added the 🐛 Bug Something isn't working | 缺陷 label Apr 16, 2025
@github-project-automation github-project-automation bot moved this to Roadmap - Chat 1.x in Lobe Chat Routine Apr 16, 2025
@arvinxx
Copy link
Contributor

arvinxx commented Apr 16, 2025

more likely your use large content?

@J-Light
Copy link
Author

J-Light commented Apr 16, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 Bug Something isn't working | 缺陷 unconfirm 未被维护者确认的问题
Projects
Status: Roadmap - Chat 1.x
Development

No branches or pull requests

3 participants