Christopher
Stoll

Firefox Beats Chrome in an Enterprise Environment

I recently wrote an article explaining how I made Google Chrome portable so that I could use it for web development testing at work. But, I have come to the conclusion that I cannot really use it in our corporate environment, it just causes frustration.

The first problem that I had was when accessing our IIS based intranet servers. Our intranet servers require domain authentication, which Internet Explorer handles seamlessly. None of the other popular browsers perform integrated authentication, which is not a problem since they will simply prompt for a username and password. This works very nicely in Firefox. However, Chrome gives the error message "Bad Request (Request Header Too Long)". This message is generated by the server and not by Chrome, but Firefox does not trigger a response like this.

When I inspect the http traffic I can see where the problem is. When the browser makes the first request, the server sends a HTTP 401 Unauthorized response. After that the browser prompts for a username and password, all of which is normal. Next, Chrome requests authorization information via Kerberos and sends that data in the authorization section of the subsequent http header. All of this should work fine in theory. The problem is that I work for a huge global company, and I am a member of many active directory groups. So, the negotiate string is very long, too long for the IIS server to handle. Firefox works because it sends a much shorter NTLM authorization string. I could request that the server team increase the maximum header size on the IIS server, but it would be hard to justify. Interestingly, if I wait a few minutes and refresh the page it will refresh properly, which I have not quite figured out.

(update, 2009-11-25: The problem above was solved a while ago, and now Chrome works well with the corporate intranet sites.)

The second problem appears when I access secure sites on the Internet. We use a proxy and web content filter, and that is configured through a proxy configuration script. Firefox automatically negotiates with the proxy and does not prompt for a username and password to access the internet, but Chrome does. Again, this is not that big of a deal, it's only needed once per session and then I can access the internet. It is interesting to note that Chrome does seem to send NTLM proxy authorization.

However, when I go to secure login sites I experience problems. I can get to the login screen, but once I enter my username and password and click submit Chrome responds with "Error 104 (net::ERR_CONNECTION_FAILED): The attempt to connect to the server failed." After I get that message I am not able to navigate to any page, even a regular insecure connection. The only option is to close the browser and start over. From a technical perspective, I can see that Chrome is requesting DNS information, and the response seems to be normal, but it never actually makes a web request.

(update, 2009-11-25: The problem above was solved a while ago, and now Chrome works well with the corporate intranet sites.)


I have been using Chrome at home, and I have had some minor issues. On problem that struck me was that Gmail reports errors periodically, but I usually click OK and continue working without problems. In spite of the minor issues I plan on continuing to use Google Chrome at home, though I am not going to remove Firefox anytime soon.

I don't think the enterprise problems I explained are strictly Chrome's fault, but the combination of Chrome and our computing environment appears to be a bad mix. I also had problems in the past with Safari, so it might be the WebKit foundations that they are both built upon. It is also possible that I have caused these problems by making Chrome portable, and I intend to run the same tests from an actual installation when time permits.

I would assume that the enterprise market is not Chrome's target audience a, but I have left the team some feedback on the problems I have experienced.

From my perspective, Firefox is the only viable option for developing web-based applications in the enterprise at this point.
Published: 2009-04-02
BloggerSoftwareWeb BrowsersGoogle