Вопрос по redirect, asp.net, response, default-document, iis-6 – Перенаправить на документ веб-приложения по умолчанию, когда указана другая страница?

2

IIS6, ASP.NET 2.0, проверка подлинности без форм

Я звоню в Response.Redirect ("~ / foo.aspx"), но для моего сайта появляется документ по умолчанию ("Default.aspx"). Что еще хуже, это происходит только с перерывами. Иногда редирект отображает правильную страницу.

Я проверил состояние сеанса и не вижу никаких значений в файле web.config (то есть я предполагаю, что я использую 20-минутные значения по умолчанию).

Хотелось бы, чтобы у меня было больше актуальной информации (я постараюсь ответить на любые вопросы).

Есть идеи? Почему он не перенаправляет на указанную страницу?

РЕДАКТИРОВАТЬ: Я заглянул в код и узнал больше деталей.

Хорошо. Там есть foo.aspx и foo2.aspx (и документ по умолчанию, Default.aspx). Все страницы расширяются от BasePage, который расширяет страницу.

BasePage имеет свойство с именем ReturnPage:

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

Пользователи нажимают на LinkButton на foo.aspx, и обработчик события click заканчивается двумя строками кода:

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

Page_Load файла foo2.aspx имеет проблемы, и его обработка ошибок вызывает Response.Redirect (ReturnPage).

Когда я просматриваю заголовки ответов foo2.aspx, местоположение 302 - это string.Empty (то есть его нет). Тот же заголовок ответа имеет тот же идентификатор сеанса ASP.NET, что и ответ foo.aspx.

И помните - это с перебоями. Иногда вы можете нажать на эту LinkButton и без усилий перейти на foo2.aspx, без проблем. Вы можете обработать щелчок с точно такими же данными один раз, и он потерпит неудачу. Вы перейдете из документа по умолчанию (Default.aspx, куда вас отправил «баг») обратно в foo.aspx, снова кликните с теми же данными (та же строка в сетке / таблице - тот же LinkButton, по существу), и вы будете перенаправлены на foo2.aspx без проблем.

Ваш Ответ

4   ответа
0

Я немного запутался здесь. Что именно вы пытаетесь достичь? Вы получаете документ по умолчанию именно потому, что 302 пуст. Ваше «непоследовательное» поведение почти наверняка связано с тем, как вы сохраняете данные в сеансе.

Реальная проблема заключается в том, почему вы перенаправляете, когда foo2.aspx «имеет проблемы». В чем здесь проблема? Зачем перенаправлять? Если вам действительно нужно перенаправить, почему цель перенаправления изменилась? Сделайте это статической страницей сообщений об ошибках, и все будет в порядке.

Я унаследовал код. Я не хочу защищать это (иногда наоборот), но я хотел бы понять это, и я не понимаю, почему 302 пуст. Единственное объяснение, которое я могу придумать, заключается в том, что значение, которое помещается в сеанс с помощью foo.aspx, отсутствует, когда foo2.aspx запрашивает его, и я не могу понять, что заставляет значение покинуть сеанс после его размещения там (опять же, по foo.aspx). lance
0

После того, как вы перенаправите и получите новый экземпляр BasePage из foo2.aspx, не станет ли это свойство ReturnPage снова нулевым? Затем, как только ваша страница загрузится с ошибками и попытается перенаправить ее, она получит доступ к пустой строке. Может быть, попытаться бросить это свойство в сеансе

Session.Add("ReturnPage","~/foo.aspx") 

вместо

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

Конечно, вам придется изменить эту обработку ошибок в загрузке страницы, чтобы захватить ее вне сеанса, а не свойства, и вам, возможно, придется переосмыслить работу всего перенаправления в вашей системе, если это окажется проблемой.

РЕДАКТИРОВАТЬ: Чтобы проверить эту идею о том, что свойство не задано или задано правильно .... (просто чтобы проверить, я не предлагаю вам жестко прописать путь там), измените ваш метод получения на приведенный ниже пример, а затем проверьте, оно работает. Надеюсь, это поможет, мне любопытно узнать, в чем проблема, если это не проблема.

get { 
   if (Session["ReturnPage"] == null) { 
        Session["ReturnPage"] = "~/foo.aspx"; 
    } 
    return Session["ReturnPage"].ToString(); 

} 
Должно быть, я полностью проигнорировал то, что вы имели в фрагменте кода, мои извинения. Однако, согласно фрагменту, если он равен нулю, получатель не собирается ничего делать, но возвращает пустую строку. Я делаю правку к этому ответу. AGoodDisplayName
Если я не читаю геттерную и сеттерную реализацию ReturnPage неправильно, это сеттерделает сохранить значение (помещаемое foo.aspx) в сессию и экземпляр foo2.aspx BasePageдолжен вытащить из сеанса и вернуть значение foo.aspx, помещенное в сеанс (то естьне вернуть пустую строку). lance
1

Размещение значения в сеансе непосредственно перед Response.Redirect () рискованно.

Изменение Response.Redirect () в foo.aspx на следующее может более надежно сохранить значение сеанса:

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

ОБНОВИТЬ: Это было исправлено только путем перемещения нашего состояния сеанса в SQL Server. Смотрите связанный вопрос:Почему / когда сеансовые записи уязвимы для завершения потока?

Это оказалось побочным эффектом большей проблемы записи уязвимых сессий перед Response.Redirect ().stackoverflow.com/questions/2267818/... lance
@Bryan: Приоритеты здесь еще не позволили мне проверить это. Я хочу, и я опубликую результаты, как только у меня есть. lance
Это решило проблему? Bryan
0

Когда ты сказал:

Иногда редирект отображает правильную страницу.

Это просто происходит, и вы не уверены, есть ли определенные страницы, которые затронуты этой проблемой? Если это так, то у вас, вероятно, есть проблема с адресацией. Вы можете использовать относительный путь или абсолютный путь, а не путь приложения. Я также предположил бы, что вы пытаетесь либо перейти на страницу из подкаталога на вашем сайте, либо в подкаталог на вашем сайте. Если вы решите придерживаться пути относительно приложения, убедитесь, что вы принимаете во внимание этот подкаталог. (напр .: ~ / FooPages / Foo.aspx)

Вот хорошая справочная страница, которую я только что нашел:http://nathanaeljones.com/129/types-of-asp-net-paths/

Посмотрите детали, которые я только что добавил к вопросу. Все эти страницы находятся в корне сайта. Обычно я не использую ResolveUrl () при передаче значения в Redirect (), но я не могу не думать, что, если бы это была проблема синтаксиса, это не происходило бы периодически. lance

Похожие вопросы