Tuesday, May 9, 2017

Some Microsoft sites returning Bad Request in Google Chrome

Some Microsoft sites returns the following HTTP error in Google Chrome only 



Bad Request 

Error parsing headers: 'limit request headers fields size'


Microsoft's OpenDx  learning site returns a Bad Request (May 4th-6th, 2017, May 25, 2017) in Chrome.

https://openedx.microsoft.com/


This is new Microsoft Learning site hosted on Azure (Microsoft's cloud service) using Open edX an open source training platform from Harvard and MIT. 


Explanation



This is caused by a browser initial accessing the page on the server. The server is asking for information in an HTTP request from the browser, usually this is an cookie that in part contains your authorization information. Each time you access the site the cookie is updated and depending on its design, it can grow. If it grows two large then you can get a Bad Request error from the server. If you get this error, then the new cookie information is never set for this domain.


This can also be caused by changes to code in the page setting a new cookie definition, or a change to web server configuration. If web server is being rebuilt nightly, this this could cause this affect the cookie definition, invalidating previous cookies.


Solution


Clear your Chrome cookies with a free tool (see my post on this) for opendx.microsoft.com to verify and delete them. You do not have to clear all your cookies for all sites. 

It seems for the openedx.microsoft.com Chrome is not expiring its cookies properly. 


But the error may persist, depend where you are on the build cycle of this site. 



I will demonstrate that this is not a cookie issue for me. On May 4th, 2017 and May 25, 2017 https://openedx.microsoft.com/ had this error in Chrome. 


I cleared my cookies for opendx.microsoft.com and still I could not get into the site. 

I revisited the page and check the cookies for opendx.microsoft.com and Chrome doesn't even have a chance to set a cookie. 

However in Mozilla Firefox, for the site https://openedx.microsoft.com/ sets a csrftoken cookie, but not in Chrome. 

In this instance, it probably is a server configuration error. Following that lead, I found 
openedx.microsoft.com is running on Nginx server.  Read my post on how to get the server manufacturer using curl for windows, to check this issue for other servers.

Nginx servers have a small default header size, see below. 



In the end, this error will be resolved quickly, usually in the same day, because the site cannot negate Chrome representing 60% of market share for long.



But in the meantime, use Microsoft IE or Mozilla Firefox browser instead, until this is server configuration is fixed.


NGIX Server Hosted Websites cookie issue 


Lately the Bad Request error is occurring many times on Microsoft and Microsoft Affiliated Websites when using Chrome.

One began to suspect that this was a ploy by Microsoft to generate traffic for IE. However, most likely its just poor developer testing.

For sites hosted on NGIX servers, this header buffer size is only 8k. 

Syntax:large_client_header_buffers number size;
Default:
large_client_header_buffers 4 8k;
Context:httpserver
What generally happens is that all the cookies used by your site get combined into one header and that may cause you to go over the default limit which is 8192 bytes.

The solution is to just bump the request limit. You can do this globally or just for your site with the LimitRequestFieldSize directive.

This is a tricky error to catch as it only affects people who have cookies over the allotted capacity. Some of your users might experience issues when their cookie size exceeds 8k or like in my case, some pages that set additional cookie value might push you over the limit.

In the first scenario once the user has cookies that are over the limit they wont be able to use the site any more while other users might access the same pages with no problem while their cookies are under the limit. 

Microsoft Websites hosted on IIS issues

In some instances, when authentication is required by a site using Microsoft Live credentials, Bad Request error was showing up because the site is hosted on Microsoft IIS.

Microsoft Sites and affiliated sites use common infrastructure for their credential store using Microsoft Passport, which lets users authenticate to a Microsoft account, an Active Directory account, a Microsoft Azure Active Directory (AD) account, or non-Microsoft service that supports Fast ID Online (FIDO) authentication.
According to the official the Microsoft definition for Bad Request for IIS Web Server for following reason;  


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.

So if the authentication token is too big, it would cause the Bad Request error. However, this problem peaked about 2 years ago and now has subsided, but mentioned for completeness.

So we are left with the remaining reason; generally no funds or time to do the right testing.


The default Microsoft IIS Web Server Header Limits is 64K, which is quite sufficient, but can break, if integrated systems testing is not part of the project plan



For Microsoft IIS HTTP Server, this limit is set by Header Limits <headerLimits> directive (default 64K). The Header Limits <headerLimits>  directive allows the Web server administrator to reduce or increase the limit on the allowed size of an HTTP request header field. The  element of the  collection contains a collection of elements that specify the maximum size in bytes for HTTP headers. 


Chrome Acceptance Header Size  (not the problem)


Chrome can accept a header size of max 256Kb. 


Actual limit seems to be 256KB for the whole HTTP header. Error message appears: "Error 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Unknown error."

No comments:

Post a Comment