IIS 7 and Above
TransferRequest vs Transfer
Last post Oct 23, 2008 03:48 AM by Gudea71
Oct 08, 2007 02:12 PM|Luis Abreu|LINK
not sure if this is the correct forum to put this question. if it's not then please redirect me to the correct one. I'm under the assumption that with IIS 7 we should use the TransferRequest method instead of the Transfer method to perform a server side
transfer in an ASP.NET application. What i've noticed is that using this new method makes my app run at least 10xs slower than when I use the old Transfer method. One more thing: when i use this method I simply loose the Params collection on my final destination
Is this a known issue?
Oct 09, 2007 04:21 PM|mvolo|LINK
You are right, TransferRequest is a new method intended for doing rewrites in IIS7. There are quite a few methods for rewriting and redirecting server-side execution already available in ASP.NET, including HttpServerUtility.Transfer, HttpServerUtility.Execute,
They all have slightly different behavior and require you to pick what makes more sense for your application. There is no *right* way to do rewriting, although, if you were to pick the most generally correct way to do it on IIS7, it would be TransferRequest.
HttpServerUtility.TransferRequest performs a full IIS child request under the covers, which allows it to re-run the entire request pipeline for the new request as if it was a separate request, getting the correct configuration for it, and running all of
the normal IIS modules including authentication, authorization, etc. For example, IIS will apply the authorization rules for the new url, as opposed to the previous url.
Re: Params issue. This is known - you have to call TRQ before the first access to the Params collection is made (typically in a module early in the pipeline), otherwise the current request will consume the entity body and it will not be available to the child
HttpServerUtility.Transfer basically maps and executes a new ASP.NET Page (or serves a static file) corresponding to the url provided. It does this in-place in the current request pipeline, without applying new configuration to the new url, or re-running
IIS modules for the new url. Because of this, its very fast, but it also prevents a lot of scenarios that are possible with TRQ.
Notably, it doesnt allow you to rewrite to any handler, just to ASP.NET pages and static files.
HttpContext.RewritePath is the middle ground, because it performs a full rewrite, but in-place. It does allow you to remap the request to any handler. But, it also doesnt re-run features for the new url, and does not pick up configuration for the new url.
It must be called prior to MapRequestHandler to correctly remap the handler.
Hopefully this sheds some light on the options.
IIS Core Server
Visit mvolo.com for more inside information on IIS7, IIS and ASP.NET
Oct 09, 2007 06:04 PM|Luis Abreu|LINK
Thanks for making everything clear now.
btw, regarding the long time problem, i think i've already understand what's going on, but i'm still not sure if can give more info about it now...
Oct 09, 2007 09:27 PM|Luis Abreu|LINK
Mike, I've just noticed that you're a MS employee and you may already know what i was talking about in the previous post :)
Anyways, I've written about it here:
Apr 09, 2008 08:28 AM|yosnoor|LINK
I know this is a relatively old thread, but I was wondering if you could tell me whether TransferRequest can transfer to a page running under a different application pool. I know this was not possible with Transfer, and wondered if it could be done with
Apr 10, 2008 06:08 PM|anilr|LINK
No, TransferRequest cannot transfer to a different app-pool.
Oct 23, 2008 03:48 AM|Gudea71|LINK
Sorry for posting here (a very old thread).
This is a very clear explanation about differences between those techniques for redirecting.
I am looking for some advice on which would be the best one for what I am looking for.
I have a web application where some links are relative "/somedir/page.aspx", some others are this way "./somedir/page.aspx", there are some form submitions, and there are some Ajax callbacks...
I need to force for all of them an SSL connection. I am planning to put some code in the Global.asax's
Application_BeginRequest to redirect every request to an SSL one (https).
Which technique should I apply?
Response.redirect looses all post and get information.
Server.transfer leaves the http: original URL so every call to the server will be transformed in a redirection, so, Its possible that every time I will get a secure zone entering warning from IE.
TransferRequest says that it needs a "pipelined something..." (I belive I need IIS7)