0

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Request Too Long</h2>
<hr><p>HTTP Error 400. The size of the request headers is too long.</p>
</BODY></HTML>

I have a c# web api along with angularjs webapp that is behaving rather weird on a deployment server.

It randomly throws 400 Bad Request error for same Web API calls that worked a second ago. Initially deleting cookies and clearing cache would fix these errors, but since the past few days, even that doesn't work.

I checked my header size, it is well within limits. I have 4 cookies almost 4 MB each, so that shouldn't be an issue.

Also, this happens only on a QA environment (load balanced with 2 boxes) but not on any other environments.

Any suggestions?

EDIT: Here is the browser's response Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.

J. Doe
  • 53
  • 1
  • 7
  • 2
    What exactly does the 400 error itself say? Please use your browser's Developer Tools to grab the whole response body and edit your question to include that. – Lex Li Oct 12 '18 at 18:11
  • @lex-li - added the response – J. Doe Oct 12 '18 at 22:07
  • 1
    I disagree with your statement - `I have 4 cookies almost 4 MB each, so that shouldn't be an issue`. Cookies that big are going to be an issue (the RFC requires user agents support cookies of "at least 4KB"). I'm assuming youve modified IIS/http.sys at the server level to accept such large headers, but not your load balancer? This sounds like an architectural issues your trying to solve through configuration, and one that will reduce performance and security in the process. What changes have you made for this to work locally? Why are your cookies 12 megabytes in total? – MisterSmith Oct 14 '18 at 11:12
  • @MisterSmith I don't know why cookies are so large..but they only hold claims from Okta (token and some of my custom claims) – J. Doe Oct 15 '18 at 15:50
  • My app creates upwards of 9 cookies if a user role has all claims in which case my **Admin** user will have. Users don't have any claims directly, only the claims they pick up by the role they are in. – djack109 Nov 23 '19 at 10:27

2 Answers2

0

The issue was large cookie size resulting from too many claims that I was storing in it. Addressed it by reducing the number of claims (custom claims) which weren't needed and now it works fine.

Will need to figure out in the future, alternative ways to pass the user's claims going forward should the app indeed have that many claims.

J. Doe
  • 53
  • 1
  • 7
  • Seems a bit stupid Microsoft gives you all that power only the have you shot down by the browser. I'm trying to write an application that requires so quite intricate security, seems now I have to rethink that part – djack109 Nov 21 '19 at 17:25
  • yeh @djack109, I suggest using roles or claims-matrix to resolve it. – J. Doe Nov 22 '19 at 18:04
  • I already have a roles/claims matrix that's the problem. I have 4 roles each of which can have up to 20 available claims. The admin role gets all claims, hence anyone in the admin role has all the claims. And those claims seem to be stored in the cookie rather than being fetched at run-time which is what I have done in the past when I rolled my own security. My users don't have any claims directly, only the claims they pick up by the role they are in. – djack109 Nov 23 '19 at 10:25
0

We had a similar issue, and could not shrink the number of claims as our SSO passes through every AD group in which a user is a member, and many of our users are in a large number of groups.

I found the answer that worked for me in StackOverflow:

Check the MSDN:

Cause

This issue may occur when the user is a member of many Active Directory user groups. When a user is a member of a large number of active directory groups the Kerberos authentication token for the user increases in size. The HTTP request that the user sends to the IIS server contains the Kerberos token in the WWW-Authenticate header, and the header size increases as the number of groups goes up. If the HTTP header or packet size increases past the limits configured in IIS, IIS may reject the request and send this error as the response.

Resolution

To work around this problem, choose one of the following options:

A) Decrease the number of Active Directory groups that the user is a member of.

OR

B) Modify the MaxFieldLength and the MaxRequestBytes registry settings on the IIS server so the user's request headers are not considered too long. To determine the appropriate settings for the MaxFieldLength and the MaxRequestBytes registry entries, use the following calculations:

Calculate the size of the user's Kerberos token using the formula described in the following article:

New resolution for problems with Kerberos authentication when users belong to many groups http://support.microsoft.com/kb/327825

Configure the MaxFieldLength and the MaxRequestBytes registry keys on the IIS server with a value of 4/3 * T, where T is the user's token size, in bytes. HTTP encodes the Kerberos token using base64 encoding and therefore replaces every 3 bytes in the token with 4 base64 encoded bytes. Changes that are made to the registry will not take effect until you restart the HTTP service. Additionally, you may have to restart any related IIS services.

If MaxFieldLength is set to its maximum value of 64 KB, the MaxTokenSize registry value should be set to 3/4 * 64 = 48 KB.

Mike
  • 629
  • 5
  • 18