With the retirement of IE11, many Windows users find it challenging to determine the Security Zone of a URL by the traditional method of opening a webpage in IE and checking the page properties. This poses a significant inconvenience for system administrators and security analysts since Security Zones are crucial for understanding the safety of URLs and their interaction with the system's security policies.
The 2019 July update: KB4507460 of Windows 10 version 1607 and Windows Server 2016 has a known issue where Internet Explorer 11 and applications using JavaScript or the WebBrowser control may fail to run. Logic App Editor in Visual Studio is also affected by this issue since it uses Internet Explorer render engine: mshtml.dll and jscript9.dll to display the webpage in Visual Studio. The provided workaround in KB4507460 does not fix the issue of Logic App Editor as Visual Studio has its private registry keys, this article will show you how to work around this issue by changing Visual Studio private reigstry key. Latest update: Microsoft has fixed this issue in 2019 August cumulative update: KB4512517.
HTTPS is widely used on Internet to secure the data being transferred. However, when a browser needs to send a HTTPS request through proxy, since the request hostname and port number are all encrypted in HTTPS request header and even the proxy cannot get them, then how does the proxy know where to send client's request? To solve this problem, the browser sends a HTTP request with method CONNECT and the target hostname and port number to the proxy. When receiving the CONNECT request, the proxy establishes a TCP connection to the requested hostname on the specified port and then returns HTTP 200 response to tell the browser the requested connection was made. After that, the proxy should just blindly forward the packets back and forth between the client and the server without looking at them until the tunnel is closed.
Before solving website compatibility issue in IE11, we need to understand the nature of compatibiltiy issue and our target. Most webpage compatibility issues in IE11 can be divided into following two scenarios:
After upgrading to IE11, web page layout may be broken. The most common reason is the web page runs in a newer document mode in IE11. However, the layout issue might still occur even if the document mode is same as before. This is because IE11 uses natural metrics for font rendering while previous IE versions use Windows Graphics Device Interface (GDI) metrics.
Compatibility view is unable to resolve all compatibility issues in Internet Explorer 11. Enterprise Mode was first introduced in April 2014 IE11 cumulative security update. It was originally aimed at emulating the behaviors of IE7 and IE8 to avoid the common compatibility problems associated with web apps written and tested on older versions of Internet Explorer. Later update of this feature added the ability to specify the document mode (5~11) for a certain website. In order to use comprehensive functions of Enterprise Mode, please first update IE11 to the latest version: KB4018271.
Compatibility View is the most common backward compatible solution in Internet Explorer, it can be configured by Compatibility View Settings, Group Policy and Local intranet security zone. We can control some of the sub-domains to be displayed in Compatibility View and some of them not by using these configurations.
Browser Mode determines the User-Agent that Internet Explorer sends to servers and the document mode Internet Explorer defaults to. This article is going to explain the relationship between them in detail.
I recently encountered an issue that a webpage does not function in IE11 with exception "SEC7111: HTTPS security is compromised by (null)". It turned out it was caused by using document.write() function in the HTTPS webpage.
Recently I was adding comment function to my blog article pages, IE always prompted message: "Internet Explorer has modified this page to help prevent cross-site scripting" when browsing a specific article page. After debugging by Fiddler, I found the reason was that the article title began with: JavaScript: , which triggered the XSS filter considering it as a javascript protocol string and blocking the web page. Actually the title was just a normal string without any script code.
Beginning January 12, 2016, older versions of IE browser (8~10) will not be supported anymore. A growing number of enterprises and individual customers start migrating to Internet Explorer 11. Upgrading to IE11 is an easy job for individual customers, however it could be challenging to IT administrators in large enterprise as they need to ensure the success of hundreds and thousands PCs.