Tuesday, October 10, 2006

Server.Transfer versus Response.Redirect in ASP

When sending a user to another page, most programmers in ASP use Response.Redirect. Response.Redirect sends a message to the browser, telling it to go to another page:
Server.Transfer is similar in that it sends a user to another page, but it has some distinct advantages and disadvantages.

First, the big drawback of Server.Transfer is that it can only send users to a page running on that server. You can't use Server.Transfer to send a user to an external site. Only Response.Redirect can do that.

Transferring to another page using Server.Transfer conservers server resources. The transfer takes place on the server instead of forcing the browser to redirect to a new page. This means fewer HTTP requests coming through and can make your applications run more efficiently.

Server.Transfer maintains the the original URL in the browser.

Server.Transfer has a second parameter — "preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to. This technique is great for wizard-style input forms split over multiple pages.

Don't confuse Server.Transfer with Server.Execute, which executes the page and returns the results.

When the Server.Transfer method is called, execution of the first page is terminated and execution of the second page begins. If the first page has started writing to the response buffer, the second page appends to the buffer instead of replacing it. If buffering is on, then HTTP headers can be modified by the ASP file that it is transferred to. If buffering is off, the HTTP headers are not modifiable by the ASP file that it is transferred to, unless no content has been sent by ASP yet. Additionally, multiple transfers can be called in succession, thereby chaining pages together.

The only data transferred to a second ASP page are the ASP built-in objects and the ASP Error object values from the first request. Any variables declared by the first ASP page are not available in the second ASP page.

Server.Transfer has several advantages over Response.Redirect:
  • Because it saves a round trip between the server and the browser it's faster and reduces the load on the Web server.
  • The Response querystring and form collections are preserved during the transfer. As a result, you don't need to worry about reposting form and querystring data to the new page.
However, Server.Transfer does have a few disadvantages:
  • You can only use Server.Transfer to redirect to a page on the same Web server.
  • You can't pass a querystring to the new page. (However, remember that the querystring passed to the page executing the transfer will automatically be passed along to the new page.) If you try to pass a querystring to the new page, you will trigger an ASP error.
  • The browser is never notified of the new page, which can cause problems with relative links in some cases.
Caution! The last point is more important than you think! I've found that this last point can be a show-stopper for using Server.Transfer. If you use Server.Transfer to transfer execution to page in a different folder, all of your relative links will break. This includes any relative links to images, anchor tags, or style sheets on the page.


Anonymous said...

I know this is old but I'm trying to find information on the topic and your post is misleading.

Namely, you confuse ASP and ASP.NET. You start off the article with an ASP example and then go on to plagiarize (http://www.developer.com/net/asp/article.php/3299641) an article written for ASP.NET.

There are not two parameters for Server.Transfer in classic ASP. Only one. You cannot preserveForm.

Tsk tsk.

Anonymous said...

Thanks what u said is correct.