Internet Explorer 11 cannot connect to local host
To be honest, I can’t remember what exactly happened when I decided there is something wrong. Remembering all the wrong things after I spend an hour trying to figure the right thing is very difficult. I installed IIS 8.5 and confirmed the following occurs: One: Internet Explorer 11 (IE11) cannot connect to
127.0.0.1 while Firefox 23 can. Two: Both IE11 and Firefox can connect to
localhost. Three: IE11 cannot connect to the local computer even when its Internet-facing IP address is used. In my example, it could not connect to
192.168.1.169. Firefox could. Four: IE11 cannot connect to a local proxy server while Firefox can. It does not matter whether the proxy server is identified with
192.168.1.169. The proxy server that I used in this example is none other than Fiddler, developers’ favorite debugging tool. Five: This issue does not occur on Windows 7 with IE11 Preview installed. I could only reproduce it on Windows 8. I did not have access to Windows Server family at the time but the test is done on a pair of freshly installed virtual machines with Windows 7 and Windows 8. I tried tweaking Internet Explorer’s enhanced protection settings to work around this issue but it was all in vain. I still think Microsoft, I or both might have missed something there. I strongly believe it should have had some effect.
This is not a surprise for those who know that the problem could be reproduced on the Metro-style instance of Internet Explorer 10 as well. Metro-style apps are sandboxed, meaning that Windows isolates them from the rest of the system. In doing so, it prevents them from circumventing isolation through network protocols. Indeed, what’s the point of isolation if an app could get the file it wanted through TCP/IP instead of file system API? Microsoft explains about this restrictions in “How to enable loopback and troubleshoot network isolation” on MSDN and introduces a command line tool that enables developers to make certain programs exempt to this isolation. Eric Lawrence, the developer behind Fiddler also explains the same thing with less technical terms in his blog post, “Revisiting Fiddler and Windows 8 Metro-style applications” and provides a graphical tool called EnableLoopback Utility to help better manage these exemptions. A project called Windows 8 Loopback Exemption Manager hosted on Codeplex also provides a similar tool. With either of these three tools, you can make a certain app running on Windows Runtime framework to be exempt from loopback traffic isolation. And now, as for Internet Explorer 11, which is a desktop app (as opposed to a Metro-style app): My experiments show that using either of the three tools, it is possible to break IE11 free from the isolation that prevents it from connecting to local system. This can only mean that IE11, at some level, takes advantage of the same isolation provided by Windows Runtime. What turns this issue into a bug is: Any by-design restriction that applies to
127.0.0.1/ must also apply to
localhost/ because they are different names for the same thing.
I tried Offline Explorer (OE) from MetaProducts, which installs a local web server for its own private use. Internet Explorer can connect to it via
localhost:800 but cannot do so via
127.0.0.1:800. Firefox can, and OE’s internal web browser control, which seems to be IE-based, has no trouble accessing the said URL. I wish I could try more apps and a couple of more scenarios (to find more bugs) but time does not allow. After all, I am not Raymond Chen of Microsoft who once made a living out of compatibility testing.
Posted on 5 September 2013, in Software Development, Software Review and tagged 127.0.0.1, Fiddler, Internet Explorer, Internet Explorer 11, isolation, localhost, loopback, Metro, proxy server, TCP/IP, web server, Windows 7, Windows 8, Windows 8.1, Windows Runtime. Bookmark the permalink. 4 Comments.