Question

IIS6, ASP.NET 2.0, No Forms Authentication

I’m calling Response.Redirect(“~/foo.aspx”), but the default document (“Default.aspx”) for my site is appearing. To make matters worse, it only happens intermittently. Sometimes the redirect displays the right page.

I’ve checked session state, and I don’t see any values in the web.config (that is, I’m assuming I’m using the 20-minute defaults).

I wish I had more relevant information to share (I’ll do my best to answer any questions).

Any ideas? Why isn’t it redirecting to the specified page?

EDIT: I’ve looked deeeeeper into the code and learned more details.

Ok. There’s foo.aspx and foo2.aspx (and the default document, Default.aspx). All pages extend from BasePage, which extends Page.

BasePage has a property named ReturnPage:

protected string ReturnPage {
    get {
        if (Session["ReturnPage"] == null) {
            Session["ReturnPage"] = "";
        }
        return Session["ReturnPage"].ToString();
    }
    set { Session["ReturnPage"] = value; }
}

Users click on a LinkButton on foo.aspx, and the click event handler ends with two lines of code:

ReturnPage = ResolveUrl("~/foo.aspx");
Response.Redirect(ResolveUrl("~/foo2.aspx"));

The Page_Load of foo2.aspx has problems, and its error handling calls Response.Redirect(ReturnPage).

When I view the response headers of foo2.aspx, the 302 location is string.Empty (that is, there isn’t one). That same response header has the same ASP.NET Session ID as the response of foo.aspx.

And remember — this is intermittent. Sometimes, you can click on that LinkButton and go effortlessly to foo2.aspx, no problem. You can process the click with the exact same data once, and it will fail. You’ll navigate from the default document (Default.aspx, where you were sent by the “bug”) back to foo.aspx, click again with the same data (the same row in the grid/table — the same LinkButton, essentially), and you’ll be redirected to foo2.aspx without issue.

Answer 1

Placing a value in the session immediately before a Response.Redirect() is risky.

Changing foo.aspx’s Response.Redirect() to the following might retain the session value more reliably:

Response.Redirect("~/foo2.aspx", false);

UPDATE: This ended up being fixed only by moving our session state into SQL Server. See related question: Why/when are session writes vulnerable to thread termination?