Response.Redirect with a fragment identifier causes unexpected refresh when later using location.hash

I was hoping someone can assist in describing a workaround solution to the following issue I am running into on my ASP.NET website on IE. In the following I will describe the bug and clarify the requirements of the needed solution.

Repro Steps:

1. User visits A.aspx
2. A.aspx uses Response.Redirect to bring the user to B.aspx#house
3. On B.aspx#house, the user clicks a button that sets window.location.hash='test'

Actual Results:

B.aspx is loaded again. The URL now shows B.aspx#test

Expected Results:

No reload. The URL will just change to B.aspx#test

Requirements:

1. Page A must redirect to page B with a fragment identifier in the 开发者_运维知识库url
2. Any user action on page B will set the location.hash
3. Setting location.hash must not make page B refresh
4. This must work on IE

Notes:

1. Bug only repros on IE (tested on ie6|7|8). Opera, FF, Chrome, Safari all have the expected results of no reload.
2. This error may have nothing to do with ASP.NET, and everything to do with IE
3. For any kind soul willing to have a look at this, I have created a minimal ASP.NET web project to make it easy to repro here

This will happen in IE if there's a directive that forbids caching on the post-redirection page. If you remove the No-Cache header, you will find that the problem no longer repros.

Here's a Meddler script that demonstrates the behavior:

import Meddler;
import System;
import System.Net.Sockets;
import System.Windows.Forms;

class Handlers
{
    static function OnConnection(oSession: Session)
    {
        if (oSession.ReadRequest())
        {       
            var oHeaders: ResponseHeaders = new ResponseHeaders();
            oHeaders["Connection"] = "close";

            if (oSession.urlContains("postRedir.asp"))
            {
                oHeaders.Status = "200 OK";
                oHeaders["Content-Type"] = "text/html"; 
                oHeaders["Cache-Control"] = "no-cache";
                oSession.WriteString(oHeaders);
                oSession.WriteString("");
                oSession.WriteString("Top of page<br /><br /><br /><br /><br /><br />");
                oSession.WriteString("<br /><br /><br /><br /><div id='firstAnchor'>Div with ID firstAnchor</div>Click this link: <A href='#secondAnchor'>#secondAnchor</A>");
                oSession.WriteString("<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />");
                oSession.WriteString("<br /><br /><br /><br /><br /><br /><br /><br /><br /><div id='secondAnchor'>Div with ID secondAnchor</a>");

            }
            else
                if (oSession.urlContains("doRedir.asp"))
                {
                    oHeaders.Status = "301 Redir";
                    oHeaders["Location"] = "/postRedir.asp#firstAnchor";                        
                    oSession.WriteString(oHeaders.ToString());          
                }
            else
            {
                oHeaders.Status = "200 OK";
                oHeaders["Content-Type"] = "text/html"; 
                oSession.WriteString(oHeaders);
                oSession.WriteString("This is a test case for http://stackoverflow.com/questions/1985056/response-redirect-with-a-fragment-identifier-causes-unexpected-refresh-when-later<BR/>");
                oSession.WriteString("Click this link: <A href='doRedir.asp'>Do Redirect</A>");
                oSession.WriteString("<form action='doRedir.asp' method='post'><input type=submit value='Submit as form' /></form>");
            }
        }

        oSession.CloseSocket();
    }
}

I have the same problem. I have tried Eric's suggestion above (without the Cache-Control header), and it still does not work. This seems to be a bug in IE for sure.

This question mentions a bug with these words: "So this bug may be is the ie bug .when web app via a redirect,the browser may only see the prev url ,so when you modify the location.hash ,the browser do the url change ,so refresh the page."

I have also tried the solution suggested there with different types of charsets, but with no success.