35

I just received the following error when I tried to run a built-in b2c edit policy from portal.azure.com. I have 2 tabs of the portal open. Why am I receiving this error?

Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.

Note: I experienced this same error message when testing active-directory-b2c-dotnet-webapp-and-webapi sample project. The reason provided was I was sending too many cookies. Is it the same problem?

If it is the same problem, shouldn't stale cookies be deleted before creating new ones?

I do see a lot of cookies for https://login.microsoftonline.com

chrome cookies node

screen shot 1 of cookies screen shot 2 of cookies

spottedmahn
  • 14,823
  • 13
  • 108
  • 178
  • Possible duplicate of [http 400: size of header request is too long when signing in user using Multifactor authentication](https://stackoverflow.com/questions/41449523/http-400-size-of-header-request-is-too-long-when-signing-in-user-using-multifac) – spottedmahn May 13 '18 at 03:03

7 Answers7

47

The error HTTP 400: Size of header request is too long generally happens because there's too many cookies or cookies that are too big.

Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.

This is bound to happen much more frequently to developers than end users as developers are logging in to the Azure portal with their corporate account, maybe also with a B2C admin account and then testing out their B2C-powered app with multiple logins.

In the long term, the answer will be is to allow Azure AD B2C customers to specify their own custom domain. This gives the application's B2C cookies isolation from everything else in login.microsoftonline.com. As of 2019-06-23, this feature is still under development. You can support this feature and keep track of its progress by voting for it in the Azure AD B2C feedback forum: Customer-owned domains

However, in the interim as workarounds, there are two things you can explore:

  1. Clear your cookies. This will definitely work every time, it's just cumbersome, especially if presented to your end users.

  2. Limit the amount of claims you include in your token. The more attributes you include in your policy, you'll end up with longer http requests which give you less margin for cookies from other Microsoft properties

Note: This is the same question as: http 400: size of header request is too long when signing in user using Multifactor authentication

2018-11 UPDATE:

Azure AD B2C allows you to use b2clogin.com instead of login.microsoftonline.com which will reduce your substantially reduce your exposure to this issue as you'll no longer share cookies with other Microsoft services.

2022-05 UPDATE:

Customer-owned domains is now live, updated the answer accordingly using strikethrough. Also, fixed the feedback link.

Saca
  • 10,355
  • 1
  • 34
  • 47
  • 6
    We switched over to using tenantname.b2clogin.com as a result of this error, and while it helped for a while, we now have users getting the same error even on this domain, so I think unless Microsoft changes how they do their cookie management, this error will keep coming back even when using a custom domain. – Chrift Jun 07 '19 at 15:21
  • Make sure you're not forgetting about #2 - Limit the amount of claims you include in the token. Whatever claims you're sending back might have big values for some users. The better practice is to have a super-trimmed down token and do a graph call to retrieve any attributes you need. – Saca Jun 23 '19 at 22:48
  • 3
    we have a very minimal token. It doesn't seem to be helping us. I am astounded that an international company such as Microsoft is peddling a product with such a huge flaw. "Don't log in too much or it will break" is essentially the advice I'm having to give to some of our service users. – Chrift Jul 11 '19 at 10:47
  • @Saca we're also encountering this issue with b2clogin.com domains. When usin custom policies, regarding "#2 - Limit the amount of claims you include in the token", which is important: the number of claims in the token, the total number of claims in the journey or the number of claims stored in the SSO session? – sgdesmet Apr 06 '20 at 12:13
2

If you are encountering "HTTP Error 400 Bad Request - Request Too Long" for your azure account, you may also want to check whether the URL has been updated by microsoft.

In my case, I wanted to check on my Azure subscriptions. I used to go to this URL: https://account.azure.com/Subscriptions

But very recently it started giving me the "Bad Request Headers Too long" issue. I checked the URL and found out that it this is now the correct place to access my subscriptions: https://account.windowsazure.com/Subscriptions

Phileo99
  • 5,581
  • 2
  • 46
  • 54
1

You also may want to check b2clogin.com described here. As per Microsoft:

  • Cookies are no longer shared with the other Microsoft services.
spottedmahn
  • 14,823
  • 13
  • 108
  • 178
Joro G.
  • 19
  • 1
1

Just an FYI: I work on B2C team and our people are looking at this issue. This is not the first time, and in fact, we've fixed it in the past so it's possibly a regression. We'll report back as soon as we have more information.

Jay Allen
  • 465
  • 3
  • 8
0

The issue is because of switching between multiple tenants and those creating cookies. We do facing this issue quite often. The only solution as of I know is deleting the cookies.

If you are a chrome lover there is an edit cookie extension, use that and try to delete the cookies of login.microsoftonline.com & portal.azure.com

Ramakrishna
  • 4,928
  • 3
  • 20
  • 24
  • 5
    While deleting cookies typically works for me, I would argue that this isn't a reasonable expectation to put on customers, especially those that aren't well-versed in cookies and how to delete them. If someone can log into many Google apps/services (using SSO) at the same time, why should it be different with Microsoft? – Rob Richardson Sep 08 '17 at 02:14
  • Customers never hit this kind of issue. Only we developers hit this kind, because of we are switching multiple tenants and multiple tenant policies. – Ramakrishna Sep 08 '17 at 02:55
  • 4
    Actually we've had several customers encounter the problem this week alone. They're using Office 365 + Azure AD B2C via our customer applications. – Rob Richardson Sep 08 '17 at 03:59
  • This can certainly happen, too, if your cookie implementation handling changes. For instance, from single to chunked. If users have old cookies that are still valid, they would receive this error. – JoeBrockhaus May 30 '18 at 18:50
0

I think the problem is with the default OWIN implementation used in the sample MVC apps, the only thing you can do is close the browser (and all other instances) and restart.

You can watch the cookie get bigger and bigger and then eventually the browser gives up.

I have not tried the approach above about the plugin but will give it a go as its a bit smoother than killing all your browser windows

whatisthejava
  • 481
  • 3
  • 12
-1

I received multiple answers that this was because I was part of too many Active Directories. I was a part of ZERO active directories when I hit this issue. I cleared my cookies and got about two steps before this happened again. The request appears to be sending many, many microsoft cookies, azure cookies, facebook cookie, google cookies, adsense cookies, and linkedin cookies in the request, but deleting them all didn't help. I finally got through using an incognito tab.

tl;dr Try an incognito tab

Shane E.
  • 85
  • 2
  • 3