views:

462

answers:

2

Hi All,

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
+1  A: 

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&lt;BR/&gt;");
                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();
    }
}
EricLaw -MSFT-
Thank you Eric.
Matt
A: 

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.

Erik Morén
This gets worse ... we have implemented the google ajax crawling technique as written here: http://code.google.com/web/ajaxcrawling/docs/getting-started.html . This means our urls includes a hash in them. Now it is like this: When clicking a link in google search page, google gives the browser a 302 redirect to our (hashed) url. As soon as the user (in IE) triggers a hash change it redirects. What is the worst, is that it continues to run the javascript code from the old page (before redirect) AND the new javascript code from the new page at the same time. :-(
Erik Morén