Last Update: Nov 19, 2024 | Published: Dec 12, 2016
What do you do when an attempt to access the Office 365 Admin Center results in the response “Bad Request – Request Too Long. HTTP Error 400. The size of the request headers is too long”?
The first action is probably to check the web to discover what a HTTP 400 error means. After reading pages of text (like this post), you’re still probably grasping for an answer. Traditional reasons encountered for on-premises IIS environments such as a Kerberos token being too large because the user is a member of too many groups are unlikely.
Too many possibilities exist to be definitive about why HTTP 400 errors occur, but when it happens with the Office 365 Admin Center, there’s a fair chance that a corrupted cookie lies at the heart of the problem.
Originally invented by Netscape back in the 1990s (and formally defined in RFC2965 as the HTTP state management mechanism) are just arbitrary strings sent to the client by the server as part of a HTTP response. There’s nothing bad about cookies as they have many valuable uses for applications, including to track user preferences. It’s hard to find a major web site that doesn’t use cookies today.
One easy way to check if a corrupt cookie is the problem when an Office 365 page refuses to display is to remove cookies for the portal.office.com site from the browser’s cache. After the cookies are removed, you can refresh the page to determine whether the problem persists.
Because removing cookies forces the Admin Center to recreate its cookies, this fix usually works. To clear the cache in Chrome, go to Settings, search for “cookies”, then select Content Settings and finally Cookies and site data. You’ll then be able to scroll down through the cookies that exist for all sites to find those held for portal.office.com (Figure 1).
You can remove a single cookie or all cookies for a site (click the X to the right-hand side). You can also take the “Remove all” option to remove all cookies for all sites. This is a tad excessive because it means that you’ll be forced to sign into every site again because cached credentials are deleted along with the cookies.
As you can see from Figure 1, the Office 365 Admin Center uses many cookies. OWA (outlook.office.com) uses even more. Selecting an individual cookie exposes some information about the cookie. For example, the content held in the s.DisplayCulture cookie for my tenant is “en-IE”, which means that “English (Ireland)” is the chosen display locale for the site. Another easily understood cookie is p.SelectedWidgets, which stores the names of the widgets displayed by the Office 365 Admin Center.
Apart from these examples, the other cookies largely hold encrypted content. Without precise knowledge of the application it’s very difficult to understand how a cookie is used. Although you can select and remove individual cookies to see if that fixes a problem, most of the time it’s simpler to remove all the cookies for a problematic site. This solution fixes issues with the Office 365 Admin Center, OWA, and the Office 365 Security and Compliance Center (protection.office.com), all of which appear to experience problems with cookies.
The steps to manage cookies for IE and Firefox are described here. IE is less informative when it comes to displaying what cookies exist for a site. Fixing a problem with a bust cookie in IE requires you to remove all cookies for the site.
Having a cookie go bad and so prevent a page displaying is one problem. Office 365 also depends on third-party cookies being enabled in the browser. If this isn’t the case, you’ll see problems when Office 365 attempts to create a new cookie, as in the case when creating a new connector for an Office 365 Group (Figure 2).
No one outside the Office 365 developers knows exactly why one of their cookies goes bad. It could be an environmental problem but the cause could equally be a poor implementation of cookie handling within the application. For whatever reason, cookie corruption is reasonably common within Office 365.
The bad thing is that cookie problems have been on the increase. The good news is that Microsoft is aware that they need to improve in this area. According to a post by Anne Michels, Senior Product Marketing Manager for Office 365:
“The engineering team is already working on this. We have a fix going on that will adress this issue for the majority of customers. We still expect some customers to see issues for a little while longer as we reduce more cookies. But we’re actively working on this.”
It seems like the HTTP 400 problem within Office 365 might be about to decline. That’s goodness. We await to see the results of Microsoft’s work in practice.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros,” the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.