Server.Transfer vs. Context.RewritePath

问题:

I understand they both don't change the URL that the client sees. Is there anything in them that makes one of them preferable over the other?
I'm planning to use it in the Application_BeginRequest in Global.asax, but also in regular aspx page.

回答1:

I think Context.RewritePath() is the better option. Reason:

Server.Transfer() throws a ThreadAbortException every time. The result of calling Response.End().

For more details read the following MS articles:

• ThreadAbortException Occurs If You Use Response.End, Response.Redirect, or Server.Transfer
• HttpServerUtility.Transfer Method on MSDN

More Information:
Server.Transfer() does not send a HTTP 302 redirect command as Response.Redirect() would do.

According to HttpContext.RewritePath on MSDN, RewritePath() is used in cookieless session state.

Also, on a different subject, Server.Transfer() and Server.Execute() are very different:

Server.Execute() returns control to the initial page immediately after where it was called.

For Example:

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

Would output:

test 1
content of include.aspx?hello=ok
test 2

回答2:

Context.RewritePath Assigns an internal rewrite path and allows for the URL that is requested to differ from the internal path to the resource. RewritePath is used in cookieless session state.

Whereas Server.transfer transfers the content assembled for processing of one page to another page .

回答3:

To avoid the exception thrown by Server.Transfer, you can use Server.Execute. Both Server.Transfer and Server.Execute DO NOT issue an 302 HTTP message. Only Response.Redirect issues this header and asks the browser to go to the new destination, claiming that it was temporarily moved. Both Server.Transfer and Server.Execute allow you to execute a different page to service current request.