Server.Transfer против Context.RewritePath

Я понимаю, что они оба не меняют URL-адрес, который видит клиент. Есть ли что-нибудь в них, что делает одно из них предпочтительным по сравнению с другим? Я планирую использовать его в Application_BeginRequest в Global.asax, но также и на обычной странице aspx.

3 ответа

Я думаю, что Context.RewritePath() - лучший вариант. Причина:

Server.Transfer() каждый раз бросает a ThreadAbortException. Результат вызова Response.End().

Подробнее читайте в следующих статьях MS:

Дополнительная информация: Server.Transfer() не отправляет команду перенаправления HTTP 302 в качестве Response.Redirect().

В соответствии с HttpContext.RewritePath на MSDN RewritePath() используется в состоянии без cookie-сеанса.

Кроме того, по другому вопросу Server.Transfer() и Server.Execute() очень разные:

Server.Execute() возвращает элемент управления на начальную страницу сразу после того, как он был вызван.

Пример:

<div>
 test 1 
 <% Server.Execute("include.aspx?hello=ok"); %>
 test 2 
</div>

Вывести:

test 1 содержание include.aspx? hello = ok тест 2


Context.RewritePath Назначает внутренний путь перезаписи и позволяет запрашивать URL-адрес, отличный от внутреннего пути к ресурсу. RewritePath используется в состоянии cookieless session.

В то время как Server.transfer передает содержимое, собранное для обработки одной страницы на другую страницу.


Чтобы избежать исключения, вызванного Server.Transfer, вы можете использовать Server.Execute. Как Server.Transfer, так и Server.Execute НЕ выдает 302 HTTP-сообщение. Только Response.Redirect выдает этот заголовок и просит браузер перейти в новый пункт назначения, утверждая, что он был временно перемещен. Как Server.Transfer, так и Server.Execute позволяют выполнять другую страницу для обслуживания текущего запроса.

licensed under cc by-sa 3.0 with attribution.