MSIE’s flawed SSL implementation

This has been quite frustrating. It seems that Microsoft has again ventured from complying with the industry web standards in this space too!

The comments from the Apache HTTP 2.x ‘http-ssl.conf’ files say it all:

#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly.
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

A little further research indicates that MSIE6 has (probably) partially fixed this (the HTTP/1.0 & KeepAlive issues), so the updated config should use a Regular Expression to look like…

SetEnvIf User-Agent ".*MSIE [1-5].*"
 nokeepalive ssl-unclean-shutdown
 downgrade-1.0 force-response-1.0
SetEnvIf User-Agent ".*MSIE [6-9].*"

Related Information:


MSIE6 CSS issue ‘dotted’ behaves like ‘dashed’

Another fix in MSIE7 (broken before), ‘dotted’ is now implemented, in MSIE6 dotted had the same visual representation as ‘dashed’.

This explains why you might expect to see a line of “……” that appear to be “——“, even when you’re absolutely positive that you’re CSS is correct!

border:1px dotted #fff;

HTML Example:

<title>dotted-dashed Example</title>
<style type=”text/css”>
fieldset {background-color:#fcfcfc;
padding:15px 10px 0 10px;margin:0 0 20px 0;
border:1px solid #999;
fieldset div.buttons {clear:both; padding-top:10px;padding-bottom:10px;margin:3px 0 0 0;border-top:1px dotted #b5b5b5;text-align:left;}
Some form fields go here…
<div class=”buttons”>
Some buttons go here…


Adding Support for ‘disabled’ OPTION tags in MSIE

This is a very annoying bug/oversight in MSIE (including the recently released MSIE7!).

For some reason, Microsoft didn’t implement the ‘disabled’ attribute on <option> tags.
All other modern (even the old Netscape 4.x) browsers support this, why would they not do the same.
This is probably for the same reason that all versions of MSIE (prior to MSIE7) left the rendering of the SELECT tag to the operating system itself, above the browser HTML.
Thankfully, you can still access the attribute on the DOM element with javascript!

My solution has evolved over time, here’s the current release code.

To emulate this behavior in MSIE, you’ve got several different challenges to overcome.

  1. You must ‘persist’ the current value of the SELECT so that you can ‘restore’ it when the user chooses a disabled field, I do this during the onload event.
  2. When the ‘onchange’ event for the SELECT tag is invoked, the currently selected OPTION’s attributes must be read and checked.
  3. If the selected OPTION is ‘disabled’, then the previous value must be restored.
  • As this solution only stores one value per SELECT, the ‘multiple’ SELECT is not currently supported.
  • In the future I’ll probably do some ‘event injection’ so that the HTML itself is cleaner. Problem is that in more complex solutions like ‘dependent dropdowns’ this becomes tricky.
  • The [if IE] ‘comment’ is critical as it is conditional logic supported only in MSIE and simplifies what was previously done via various ‘browser-sniffing’ tricks.
  • The example code in this example excludes the CDATA escapes and several tags required for valid XHTML for brevity.
  • FYI, the example also contains the MSIE background-image cache fix discussed in a previous post.

<script type=”text/javascript”>
var isMSIE=false;
<!–[if IE]>
<script type=”text/javascript”>
<script src=”/js/grv-msie-hacks.js” type=”text/javascript”></script>

<script type=”text/javascript”>
function xload(){
function xchange(obj){
// note: javascript emulation of <option disabled…> (for MSIE)

<body onload=”xload();”>

<form action=”#” method=”GET”>
<select name=”s” id=”s” size=”1″ onchange=”xchange(this);”>
<option value=”n1″>Normal1</option>
<option value=”di” disabled=”disabled”>Dis</option>
<option value=”n1″>Normal2</option>

JavaScript file (grv-msie-hacks.js):

* Code library to add several ‘broken’ features in MSIE 6 and 7
* @version $Id: $
function grvMsieInitHacks(){
function grvMsieCacheFix(){
/* Added new functions to support <option disabled…> emulation
* First part, necessary for <body onLoad…>
* builds array of all initial selections for <select>s on page (for LT or EQ MSIE7)
* WAS: disabledOptionEmulation();
function grvMsieSelectFix_init() {
if (document.getElementsByTagName) {
var allSelects = document.getElementsByTagName(“select”); // build array of all <select> tags
if (allSelects.length > 0) { // if array has values…
window.allSelectsCurrentIndex = new Array(); // new array to hold initial selections
for (var i=0, individualSelect; individualSelect = allSelects[i]; i++) { // crawl through all <select> tags
individualSelect.onfocus = function(){ window.allSelectsCurrentIndex[] = this.selectedIndex; } // fill array with selectedIndex values

/* companion code for grvMsieSelectFix_init()
* resets <option> selection if disabled to last good selection (for LT or EQ MSIE7)
* WAS: restoreSelection(inOptionChoice)
function grvMsieSelectFix_restore(inOptionChoice) {
if (inOptionChoice.options[inOptionChoice.selectedIndex].disabled){
// if new choice is disabled…
inOptionChoice.selectedIndex = window.allSelectsCurrentIndex[]; // deny selection, revert back to last ‘known good’ choice (typically, the initial selection at page load)
} else { // if new choice isn’t disabled…
window.allSelectsCurrentIndex[] = inOptionChoice.selectedIndex; // update array so last ‘known good’ choice is now the latest user selection

Hopefully, Microsoft will get around to fixing this correctly some day… maybe for MSIE8!

MSIE Conditional code

This is not so much as a MSIE bug, but rather a non-standard “feature” (added in MSIE 5.5) that is often helpful when constructing websites that you try to build with valid XHTML and CSS. As all non-Microsoft browsers will see these as simple
HTML markup comments, it gives you the flexibility to deal with the inconsistencies and quicks in the various versions of MSIE. This is particularly important for the numerous changes introduced with MSIE7.

I’ve tested this with <style />, <script /> and <meta /> tags, but wouldn’t doubt that it works anywhere (but don’t see any typical situations for that!)

Some simple instructions:

  1. Start with an HTML comment
  2. Add the opening brackets, so it resembles <!–[if …]>
  3. Add the closing brackets too… <![endif]–> (don’t forget that extra less than and bang/exclamation point!)
  4. Add the versioning info, this should be pretty obvious, but i’ll list the most common ones.
    IE 7 = MSIE7
    IE 6 = MSIE6
    IE 5.5000 = MSIE 5.5
  5. Some modifiers, (should you want a range of versions):
    lt = Less Than
    gt = Greater Than
  6. Make sure that the body content of the tag (which now resembles an HTML comment) is coded.
  7. That’s it, now be sure to test for expected behaviors!

Some Examples:

<!–[if IE 6]>
<style type=”text/css”>
/* <![CDATA[ */
html {
overflow-y: scroll;
/* ]]> */
<![endif]–><!–[if lt IE 5.5000]><style type=”text/css”>@import “/css/IE50Fixes.css”;</style><![endif]–>
<!–[if IE 5.5000]><style type=”text/css”>@import “/css/IE55Fixes.css”;</style><![endif]–>
<!–[if IE 6]><style type=”text/css”>@import “/css/IE60Fixes.css”;</style><![endif]–>
<!–[if IE 7]><style type=”text/css”>@import “/css/IE70Fixes.css”;</style><![endif]–>
<!–[if lt IE 7]><script type=”text/javascript” src=”/js/IEFixes.js”></script>
<meta http-equiv=”imagetoolbar” content=”no” /><![endif]–>


MSIE6 javascript memory leaks

Argh…. yet again, this crappy product has another bug that developers must work around!

It seems that Microsoft doesn’t release memory to javascript objects from memory when created on a page… even when the page is unloaded.

Let’s think about this one for a second, why would you want to keep a javascript variable or DOM reference in memory after the user has navigated away from that page? This violates the stateless paradigm that web applications generally work with, besides… how would a developer be able to get that information (memory) back on the next page anyways? Perhaps, it was some genious that tried to keep state in javascript when the ‘BACK’ button was pressed… we’ll probably never know.

There’s a great quote I found while researching this…

“IE has an issue where it leaks memory when a circular reference is created between a COM object and a javascript object. In IE, the DOM is implemented via COM ….. This memory is not reclaimed until the browser closes. The simplest solution is to pretend there is no garbage collector for objects and make sure you always clean-up after yourself.”


Microsoft ‘chimes in’:

Tools to help:


MSIE6 background-image caching (or lack of it…) and flickering

This has been an annoyance of this (IMHO very buggy) browser since it was first beta tested. Earlier (5.x) and newer (7.x) versions do not exhibit this problem.
For some reason Microsoft developers broke the caching mechanism for background images, particularly when defined in CSS. This makes for slow screen painting as well as wasted network traffic as each occurrence of the image becomes a new HTTP request to the webserver. This also causes a notable delay in those images painting on the screen and ‘flicker’ when the images are used in CSS rollover effects. Since the image obviously isn’t changed it results in many ‘HTTP 304 Not Modified‘ entries in the server logs.


1. You CAN/SHOULD set the Expiry for the images, however this can be problematic. Since I typically run Apache HTTPD, those instructions follow:

a) Set an explicit expiry time based on MIME types in the http.conf file.

[instructions in separate post]

b) Enable .htaccess for the server and allow its usage in individual folders on the server.

[instructions in separate post]

c) Use client-side technologies to hack around the problem…. you can use many CSS tricks, but I’ve found that JavaScript is the easiest (most compatible) method.

Add the following to a method executed in the onload event of the page…

<script type=”text/javascript”>
try {
document.execCommand(‘BackgroundImageCache’, false, true);
} catch(e) {}
NOTE: MSIE will execute the Javascript, Mozilla and other browsers will throw an exception and wind up in the catch block… which ignores the problem.

With the use of conditional comments, this can be added to an MSIE specific JS file, or even better an MSIE specific CSS file containing the following:

html {
filter: expression(document.execCommand("BackgroundImageCache", false, true));


<option disabled=”disabled”>?</option> not implemented in MSIE

This was a complete shock to me recently, even after years of ‘assuming’ that something this simple would be well supported… after all, this is pretty basic.

All modern browsers Mozilla (Firefox), Safari, Opera, even old Netscape (eg: 4.x) browsers work properly with the following code and comply with the W3C HTML specification making the value “Two” unable to be selected by the user within the browser… MSIE doesn’t comply and allows the user to select it!

<form name="example" action="#" method="get">
<select name="test">
<option value="1">One</option>
<option value="2" disabled="disabled">Two</option>
<option value="3" selected="selected">Three</option>
<option value="4" style="color:green;">Four</option>


This ‘failure’ to support standards actually seems to be due to the way the <select> tag is handled by the browser… it passes off control to the operating system (Windows). Obviously, Microsoft was able to pass along ‘other’ attributes, like ‘style’ in the example above, but chose to not support ‘disabled’.

In this case, the developer is left to find a solution… easiest is to just remove the unwanted value from the list of options, otherwise it requires extensive amounts of JavaScript.

Good luck!

NOTE: Tested on MSIE 6.0 (WinXP), hopefully Microsoft will fix this in MSIE7.

NOTE: this process is obsolete, from what I can gather it was only supported in MSIE6, and possibly MSIE7.

Use of this tag will disable the Image Toolbar (normally accessed via right-click) within MSIE. Typically it is enabled whenever an image larger than 130×130 is displayed.

Add the following to the <head> section of your webpage(s):
<meta http-equiv="imagetoolbar" content="false" />

Alternately, you COULD use some proprietary MSIE attributes on the <img /> tag.
<img src="..." galleryimg="false" />

Even when you use the META tag to disable this feature for all images, you can explicitly re-enable it with the following proprietary tag…
<img src="..." galleryimg="true" />


NOTE: this is an obsolete practice, and should be removed unless you plan to support beta versions of MSIE6.

The story behind this tag is one of virtue. Microsoft, as they do TOO often, added a ‘feature’ in beta versions of Windows XP (MSIE 6.0) that enabled the browser itself to analyze the content on a given page, and insert links to other websites. This was "e;spun" as being good the the visitors of your website, because they could be exposed to related products or services. Unfortunately, the webmaster and site owners had no say in what content was being linked or to where… which could be a competitor!

This tag was added as a method to prevent these "Smart Tags" from operating on websites… in the end, Microsoft did not leave this feature (enabled?) in the released version of Internet Explorer 6!

BTW, there are some JavaScript libraries today that offer similar functionality, but they are not related to this tag.

Add the following to the <head> section of your webpage(s):
<meta name="MSSmartTagsPreventParsing" content="TRUE" />