If you're using the new menu control that ships with ASP.NET 2.0 and SSL Termination/Acceleration, you will run into this issue. The behavior the end users will see is a warning in the browser stating something similar to:
This page contains both secure and nonsecure items. Do you want to display the nonsecure items?
The user is browsing using HTTPS, so where is the non-secure item?
This is actually caused by the way the menu control was implemented. When you hover over a menu item, the popup menu is created using frames. For performance reasons, if the URL that the server receives is HTTP, the script that builds the popup menu uses about:blank as the default page. This is done to increase performance since the browser won't have to make another request to the web server just to temporarily populate a frame. If the server receives the URL as HTTPS, the script actually makes a request back to the server to an HTTPS address to populate the frame.
So...if you use SSL termination or SSL acceleration you end up with the following network architecture:
Client --> SSL --> Termination/Acceleration device --> HTTP --> Web Server
Even though the client is using SSL, the web server is getting HTTP traffic. As a result, the menu control does not inject the script to populate the popup using an SSL address. When the client hovers over the menu item, the popup tries to go to about:blank. This is considered a protocol transfer in IE which causes the warning to display.
That was a bit long winded, but it's good to know why your getting an message before trying to change it :)
The easiest way to get the warning to go away is to manually inject the line of script that forces the client to populate the popup using an SSL address. This would look like:
<script runat="server"> protected override void Render(HtmlTextWriter writer) { Page.ClientScript.RegisterStartupScript(typeof(Page), "MenuHttpsWorkaround", Menu1.ClientID + "_Data.iframeUrl='https://myserver/someblankpage.htm';", true); base.Render(writer);
}</script>
I'm having a similar problem. I realize that this post is pretty old, but in hopes of a reply.... Here it is.
my script is:
function setHover(nav) {
var ieULs = nav.getElementsByTagName('ul');
if (navigator.appVersion.substr(22,3)!="5.0") {
// IE script to cover <select> elements with <iframe>s
for (j=0; j<ieULs.length; j++) {
//ieULs[j].innerHTML = ('<iframe src="about:blank" scrolling="no" frameborder="0" style="filter: progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);"></iframe>' + ieULs[j].innerHTML);
ieULs[j].innerHTML = ('<iframe src="https://www.domainname.com/blank.htm" scrolling="no" frameborder="0" style="filter: progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);"></iframe>' + ieULs[j].innerHTML);
var ieMat = ieULs[j].firstChild;
var width=ieULs[j].offsetWidth+0;
ieMat.style.width=width+"px";
ieMat.style.height=ieULs[j].offsetHeight+"px";
ieMat.style.zIndex="-1";
ieULs[j].style.zIndex="101";
}
// IE script to change class on mouseover
var ieLIs = nav.getElementsByTagName('li');
for (var i=0; i<ieLIs.length; i++) if (ieLIs[i]) {
// Does this LI have children? If so add a sfnode class.
if (ieLIs[i].getElementsByTagName("UL").length>0){
ieLIs[i].className+=" sfnode";
// Add a sfhover class to the li.
ieLIs[i].onmouseover=function() {this.className+=" sfhover";}
ieLIs[i].onmouseout=function() {this.className=this.className.replace(' sfhover', '');}
} else {
// IE 5.0 doesn't support iframes so hide the select statements on hover and show on mouse out.
var ieLIs = document.getElementById('nav').getElementsByTagName('li');
ieLIs[i].onmouseover=function() {this.className+=" sfhover";hideSelects();}
ieLIs[i].onmouseout=function() {this.className=this.className.replace(' sfhover', '');showSelects()}
The problem is when I dynamically create the iframe (to hide select boxes and flash controls when using a CSS menu) using
the page loads indefinetly. if I use the commented out line with about:blank the page loads properly but i get an display unsecure items popup in IE.
does anyone have any suggestions?
the solution which worked for me is... try to analyse the traffic using "fiddler" software and look for the non ssl item which your webpage is requesting... find it out in your css and javascript where you're making a reference to them.... (in layman language ;) as I'm not an expert.)
why does this exist in these situations if creators know it is a glitch caused by frames opening independently to speed up the download process? COME ON NOW!!!! Get it gone, we know you have the knowledge! Who must correct what to get it outa my brokerage page?