New Internet Explorer Knowledgebase articles
Here you go - this month's new KB articles. You know what they say.. never lose sight of your roots.. and for me, my roots are buried deep in supporting users of Internet Explorer from a technical perspective, not a spyware/malware perspective, and let's face it - when was the last time you saw a kernel32.dll error caused by a video driver? IE is *way* more stable than it used to be.
Maybe things will hot up on the Internet Explorer scene now that the IE8 beta is around the corner. I confess to feeling some excitement when I think about putting IE8 through its paces. The team have been very secretive - not even *I* know for sure what's coming.
Anyway, let's take a look at the new Knowledgebase articles for this month....
IE6 and IE7: An Internet Explorer Automatic Component Activation (IE ACA) Preview #2 update is available to disable the "Click to activate" behavior
Microsoft is releasing an Internet Explorer Automatic Component Activation (IE ACA) update that will disable the “Click to activate” behavior of the Internet Explorer ActiveX update that was originally released in April 2006.
It is strongly recommended that this update only be deployed for testing purposes.
IE5.01, IE6, IE7: MS08-010: Cumulative security update for Internet Explorer
Microsoft has released security bulletin MS08-010. The security bulletin contains all the relevant information about the security update. This information includes file manifest information and deployment options, as well as known issues.
IE6 and IE7: You may be unable to view some PDF documents in Windows Internet Explorer 7 or in Internet Explorer 6
This problem occurs because of the method that is used to determine the MIME type of downloaded content. This problem occurs even if the content MIME type is declared as "application/pdf."
IE6: If you configure Internet Explorer 6 to use a proxy autoconfiguration (.pac) script, URLs may be identified as being in the Internet zone instead of as being in the local intranet zone
This problem occurs because Internet Explorer (Iexplore.exe) starts to process the .pac script when it first connects to the network from the client computer.
If the security zone of the target URL is identified after the exception list of the .pac script is read, the Web site is displayed as being in the local intranet zone. Conversely, if the target URL is accessed before the exception list is read, the Web site is identified as being in the Internet zone.
Therefore, depending on the timing, the .pac script may incorrectly identify a URL as being in the Internet zone instead of as being in the local intranet zone.
IE6 and IE7: Internet Explorer uses HTTP/1.0 GET requests instead of HTTP/1.1 GET requests to connect to a Web site
This problem occurs because of a design change in how the Wininet.dll file reads the values of the Use HTTP 1.1 option and the Use HTTP 1.1 through proxy connections option as a policy. In this case, the Security_HKLM_Only registry entry is enabled. This design change does not consider the effect of the Security_HKLM_Only registry entry. When the Security_HKLM_Only registry entry is enabled, the default settings for the Use HTTP 1.1 option and for the Use HTTP 1.1 through proxy connections option are set to be disabled. By default, the EnableHttp1_1 registry entry and the ProxyHttp1.1 registry entry do not exist. Therefore, when the Wininet.dll file tries to read them in the registry, the values of these registry entries are determined to be turned off.
The Security_HKLM_Only registry entry is stored in the following registry subkey:
IE7: Windows Internet Explorer 7 may exit unexpectedly when you view a Web page that sets a scroll bar style attribute for an element
When you view an HTML page that uses scroll bar (scrollbar) style attributes for an element, Windows Internet Explorer 7 may exit unexpectedly. Additionally, you may receive an access violation error message in the Mshtml.dll file.
Error message when you run a script that is encoded by using Script Encoder (Screnc.exe) in Windows Server 2003 or in Windows XP
This problem occurs because the non-encoded scripts use comments as encoding markers. These comments resemble one of the following:
• '**Start Encode** for Microsoft Visual Basic Scripting Edition (VBScript)
• //**Start Encode** for JScript
These comments and the lines that come before them should be visible in the encoded script. However, they are invisible.