This post was most recently updated on February 16th, 2023.
5 min read.Every now and then, something like half of Microsoft’s websites will suddenly stop working – this applies to at least Azure Portal, SharePoint Online sites, MSDN forums, Office Online, and probably a thousand 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:
Or alternatively, you’re just stuck in an authentication loop forever. In this case, you don’t really have time to get an error message of any kind – but sometimes the solution is still the same!
In any case, 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, which 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.
Reason: Cookie mismatch
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? Why does my Outlook Web Access end up in an everlasting authentication loop with no exit in sight?
Yeah, it is a bit baffling, isn’t it?
Most of the time, weirdly enough, it wasn’t your fault, though. And it’s not the authentication infrastructure gone haywire either. Instead, 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 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!
Solution 1: log in through login.microsoftonline.com
Okay, let’s get the simple stuff out of the way first: maybe the site you’re trying to access actually does have some issues with their authentication. Maybe it’s not you, it’s them.
In this case, it’s a good idea to try logging in using Microsoft’s out-of-the-box login service. Hit the link below and try it out:
https://login.microsoftonline.com
After that, you should be able to log in to whatever service you were logging in to originally if it’s able to reuse your authentication cookie.
Did it not work? Still the same error? Okay, check out the other solution below!
Solution 2: Remove cookies for Microsoft’s domains
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. You’ll lose all the cached files, all of your existing sessions, all of the cookies, and personalization suffer – you usually don’t want that.
And before you remind me, that nuking the whole browser cache is a great option because it removes tracking cookies and ad targeting as well, let me counter that by noting that it’s the wrong solution for the right problem :) You should be either using a browser extension or a privacy-oriented browser (like Brave) if you hate ads and tracking cookies. Nuking your cache is approaching the issue from the wrong angle!
Okay, but back to the topic – almost surgically removing Microsoft’s cookies, to force a re-authentication. How to do that?
Since it’s the authentication cookie, that has somehow gone haywire, we’ll just need to get rid of it. And since you actually just want to get rid of the offending cookie and save everything else, here’s what to do!
Time needed: 5 minutes
How to remove invalid cookies for a Microsoft login (such as MSDN login) in Google Chrome
- Click on the site info area in Chrome’s Omnibox (that’s the name of the URL text box in Chrome!)
Find the “site info” area – usually showing the “lock” and possibly other security information next to the address bar (Omnibox) in Chrome (and most Chromium-based browsers).
Something like shown below:
- Click on “Cookies (x in use)”
Clicking on “Cookies” in the little dialog should open a new window for clearing the cookies per domain – well, for different domains that have set cookies for this site, anyway.
- Remove the offending domains
Next we’ll clear just the offending Microsoft domains. 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!
Now you should be good to log in. Give it a go and see how it works!
Where might this be required?
I’m guessing that you can encounter this issue on any Microsoft web property using authentication. Here’s the list where I’ve encountered the issue so far:
- Office 365 The Portal
- Different Office 365 / Microsoft 365 services, most notably:
- SharePoint Online
- Microsoft Teams
- Microsoft Office Online services
- Azure Portal
- MSDN Forums
- Tech Community
To an observant reader, the list above raises a question, though… It has some sites that DON’T require authentication! What’s up with that?
Why should I do this on MSDN forums? I’m not logged in!
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 whether it worked for you!
Further reading
- An alternative way to fix the issue in Google Chrome
- 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). While I prefer my way, his instructions might suit your needs better. Check it out here:
https://sympmarc.com/2017/01/04/fixing-the-bad-request-request-too-long-error-with-office-365-in-chrome/
- 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). While I prefer my way, his instructions might suit your needs better. Check it out here:
- MSDN Subscription Downloads and other links
- Did you come here looking for the link to MSDN Subscriptions or Subscriber Downloads? No worries – they’re right here:
The all-important MSDN Subscriber links
- Did you come here looking for the link to MSDN Subscriptions or Subscriber Downloads? No worries – they’re right here:
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- “Destination Path Too Long” when copying files in File Explorer? Easy workaround(s)! - August 27, 2024
- Where does NetSpot (wifi heatmapping tool) store its project files? - August 20, 2024
- How to fix Bitlocker failing to activate? - August 13, 2024
