This post was most recently updated on January 8th, 2019.
Every now and then, something like half of Microsoft’s websites will suddenly stop working – this applies to Azure Portal, SharePoint Online sites, MSDN forums and probably a thousand of other sites. The error is most of the time something like this:
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
Or like shown below:
This effectively blocks you from accessing the site. Most typically, I’ve encountered this on MSDN forums or Azure Portal – you just get a very blunt, unfriendly and quite useless error message, like above. This applies even to Microsoft’s services, that don’t seem to require logging in – but actually do so, in the background (like Tech Community).
This effectively blocks your access to these sites. Annoying!
Yet once again, the solution is almost stupidly simple.
This has left me scratching my head a few times – why can’t I access SharePoint Online anymore? Why do I get a Bad Request error when accessing MSDN forums? What’s this HTTP Error 400 when opening Azure Portal? Yeah, it is a bit baffling, isn’t it?
Most of the time, weirdly enough, it wasn’t your fault though. There’s something amiss with the authentication configuration – and there’s a workaround.
This seems to be simply a cookie mismatch error of sorts, and this error (in a couple of different forms, I guess) has existed on Microsoft’s different sites for quite a few years already. I’m guessing it’s caused by using multiple different accounts for authenticating against different Microsoft’s sites and services, and some of the cookies being leftover from earlier sessions and sites just trying different implicit logging in maneuvers – but failing.
In the end, all of this is just guesswork. The more important part is, that it’s easy to fix!
For whatever reason, the typical solution people propose for this issue is to clear your cache and get rid of all cookies. But if you ask me, that’s a huge overkill.
Since it’s the authentication cookie, that has somehow gone haywire, we’ll need to get rid of it. Since you actually just want to get rid of the offending cookie and save everything else, here’s what to do!
- Click on the site info area in Chrome’s Omnibox (that’s the name of the URL text box in Chrome!)
- Click on Cookies (x in use)” (see picture for “Step 1” below).
- This should open a new window, where you can see different domains that have set cookies for this site (see picture for “Step 2” below).
- Click “Remove” while you’ve selected the domain you were logging in for (or if “login.microsoftonline.com” exists, you can select it, too).
- After removing the cookies, you should be able to log in successfully when refreshing the page!
On some pages, such as MSDN forums, the log-in action might be implicit (it happens automatically in the background). Hence you won’t be ever asked any questions or asked to do any logging in actions. But if you can now access the site, the fix worked.
Let me know if it didn’t work for you!
The same issue has been noticed elsewhere on the internet – and one of my favorite bloggers out there, Marc D Anderson, describes another way to fix this (through Chrome’s settings instead of site settings). Check it out here: https://sympmarc.com/2017/01/04/fixing-the-bad-request-request-too-long-error-with-office-365-in-chrome/
Latest posts by Antti K. Koskela (see all)
- Fixing “An assembly specified in the application dependencies manifest [projectname].deps.json was not found” - February 13, 2019
- What is “fp.js” – and why is it snooping on your SharePoint usage? - February 6, 2019
- Google Plus is shutting down – fix your .NET OAuth flow! - February 4, 2019
- Solving yet another “Microsoft.SharePoint.Client.ServerException: Unknown Error” - January 29, 2019