Я понимаю, что они оба не меняют URL-адрес, который видит клиент. Есть ли что-нибудь в них, что делает одно из них предпочтительным по сравнению с другим?
Я планирую использовать его в Application_BeginRequest в Global.asax, но также и на обычной странице aspx.
Server.Transfer против Context.RewritePath
Ответ 1
Я думаю, что Context.RewritePath() - лучший вариант.
Причина:
Server.Transfer() каждый раз бросает a ThreadAbortException. Результат вызова Response.End().
Подробнее читайте в следующих статьях MS:
- ThreadAbortException возникает, если вы используете Response.End, Response.Redirect или Server.Transfer
- HttpServerUtility.Transfer Method на MSDN
Дополнительная информация: Server.Transfer() не отправляет команду перенаправления HTTP 302 в качестве Response.Redirect().
В соответствии с HttpContext.RewritePath на MSDN RewritePath() используется в состоянии без cookie-сеанса.
Кроме того, по другому вопросу Server.Transfer() и Server.Execute() очень разные:
Server.Execute() возвращает элемент управления на начальную страницу сразу после того, как он был вызван.
Пример:
<div>
test 1 <br/>
<% Server.Execute("include.aspx?hello=ok"); %>
test 2 <br/>
</div>
Вывести:
test 1
содержание include.aspx? hello = ok
тест 2
Ответ 2
Context.RewritePath Назначает внутренний путь перезаписи и позволяет запрашивать URL-адрес, отличный от внутреннего пути к ресурсу. RewritePath используется в состоянии cookieless session.
В то время как Server.transfer передает содержимое, собранное для обработки одной страницы на другую страницу.
Ответ 3
Чтобы избежать исключения, вызванного Server.Transfer, вы можете использовать Server.Execute. Как Server.Transfer, так и Server.Execute НЕ выдает 302 HTTP-сообщение. Только Response.Redirect выдает этот заголовок и просит браузер перейти в новый пункт назначения, утверждая, что он был временно перемещен. Как Server.Transfer, так и Server.Execute позволяют выполнять другую страницу для обслуживания текущего запроса.