I have an ASP.NET application that implements keep-alive by using a hidden IFRAME with a refresh header (or meta refresh tag in the page).
For many - but not all - instances of Internet Explorer (reproduced so far on IE7 and IE8 beta - but not for everyone!) if you move between two secure pages that both contain this keep-alive IFRAME, you get something like this sequence of events:
0s: load page1.html - includes keepalive.html, schedules a refresh at 15s
5s: click the page2 link
load page2.html - includes keepalive.html, schedules a refresh at 20s
15s: refresh of frame on page1 happens; mixed content error box displayed
At this point the error "This page contains both secure and non-secure content" is displayed in the browser.
page1.html:
<html><head><title>Page 1</title></head><body>
<h1>This is Page 1</h1>
<p><a href="page2.html">Go to Page 2</a></p>
<iframe src="keepalive.html" width="500" height="200" />
</body></html>
Page 2 is the same but says Page 2, and links to Page 1, instead.
keepalive.html:
<html><head>
<meta http-equiv="refresh" content="15" />
</head><body>
<h2>This is the keep alive</h2>
</body></html>
In all the browsers I have tested this in I have ensured that the internet zone has permission to do a meta refresh and is set to prompt when displaying mixed content. I have read all the pages suggesting that you need to have a src="" tag on your IFRAME or IE will consider it insecure - by design it has to have a src tag, which is that of the keep-alive page.
If you sit on Page 1 forever, the IFRAME refreshes fine. The error only shows up the first time after you change to Page 2.
I am looking for a way to fix this with minimal change: a better method for keep-alive would be to use a control & automatically-refreshing images, which I will investigate for future versions. A possible workaround I have in mind is having contents of the IFRAME be a regular XMLHttpRequest to the server, instead of a meta refresh. A simpler bugfix would be even better.
Update: I have marked Grant Wagner's answer as correct because it lead me to the actual problem: the Lenovo Password Manager add-on, CpwmIEBrowserHelper, causes this error. This neatly explains why some people see this problem and not others - most of the people I asked have ThinkPads. Disabling the extension makes the refresh problem go away.
As we can't cause everyone who might use the application to fix this problem, we are going to go with a javascript timer and refreshing the window location, updating the keepalive.html page to look like this:
<html><head>
<meta http-equiv="pragma" content="no-cache">
</head><body>
<h2>This is the keep alive</h2>
<script type="text/javascript">
setTimeout ('ReloadPage()', 15000 );
function ReloadPage() {
window.location = window.location;
}
</script>
</body></html>