|
Introduction
Active Server Pages 3.0 offers many improvements and changes, most dealing with reliability, performance, and scalability, but Microsoft also added two new methods to the Server object: Transfer and Execute. (This version of ASP is part of IIS 5.0, which ships with Windows 2000.)
Server.Transfer
ASP developers have used Response.Redirect since the days of ASP 1.0 to redirect the browser to another page. Perhaps, like me, you thought this was all occurring on the server and was thus a fairly efficient operation, but that's not how it works. When the ASP engine encounters a Response.Redirect method, it stops the processing of the current page and sends an HTTP redirection header (302 Redirect) to the client, informing it that the page it requested has moved and can be found at a different URL. When this response is sent to the browser, the browser requests the new URL and the ASP engine sends the new page to the client. Thus, the redirection of a page using Response.Redirect requires an extra client/server round trip.
Server.Transfer works differently than Response.Redirect. When the ASP engine encounters a Server.Transfer method on the page, it stops processing the page and sends the new page to the client in the response. That is, Server.Transfer substitutes the request for one page with another without involving an extra round trip between the server and the browser. In fact, as far as the browser is concerned, it received the page it originally requested.
Let's illustrate with an example. Say you wished to branch in your ASP code and send users to one page or another based on whether they were using Internet Explorer or some other browser. The following code from Redirect1.asp accomplishes this employing the Browser Capabilities component and the Response.Redirect method:
Here's the code behind Redirect.1.asp:
<%@ Language=VBScript %>
<%Option Explicit%>
<%
Dim brws, strBrowser
Set brws = Server.CreateObject("MSWC.BrowserType")
strBrowser = brws.browser
Set brws = Nothing
If strBrowser="IE" Then
Response.Redirect("TargetIE.asp")
Else
Response.Redirect("TargetOther.asp")
End If
%>
If you attempt to navigate to Redirect1.asp using Internet Explorer, you should end up with a page that looks like the one shown in Figure 1.
Figure 1. Redirect1.asp redirected the user to this page using the Response.Redirect method.
Notice that the URL of the page is the URL of the redirected page, not the original page. Transfer1.asp achieves the same result as Redirect1.asp using Server.Transfer:
<%@ Language=VBScript %>
<%Option Explicit%>
<%
Dim brws, strBrowser
Set brws = Server.CreateObject("MSWC.BrowserType")
strBrowser = brws.browser
Set brws = Nothing
If strBrowser="IE" Then
Server.Transfer("TargetIE.asp")
Else
Server.Transfer("TargetOther.asp")
End If
%>
When you attempt to navigate to Transfer1.asp using Internet Explorer, you end up with a page that looks like the one shown in Figure 2.
Figure 2. Transfer1.asp redirected the user to this page using the Server.Transfer method.
Because the redirection was performed entirely on the server, without any extra round trip between server and browser, as far as the browser is concerned it has received the Transfer1.asp page. You can verify this by looking at the URL shown in the Address box.
Not All Good
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.
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. For example, here's the source code for Transfer2.asp:
<%@ Language=VBScript %>
<%Option Explicit%>
<%
Dim brws, strBrowser
Set brws = Server.CreateObject("MSWC.BrowserType")
strBrowser = brws.browser
Set brws = Nothing
If strBrowser="IE" Then
Server.Transfer("SubFolder/TargetIE2.asp")
Else
Server.Transfer("SubFolder/TargetOther2.asp")
End If
%>
Notice that this page is identical to the Transfer1.asp with one exception: the target pages are located in a subfolder (appropriately named "SubFolder") of the Web site. This time, when you attempt to navigate to Transfer2.asp using Internet Explorer, you end up with a page that looks like the one shown in Figure 3.
Figure 3. The links to the image and hyperlink on this page are broken because we used Server.Transfer to transfer to a page in a different folder.
Notice that the link to the image is broken. In addition, if you click on the hyperlink on the page you will get a "Page Not Found" message. This happens because the browser thinks that the relative links on the page are relative to the location of Transfer2.asp, not the location of SubFolder/TargetIE2.asp. In contrast, Redirect2.asp page, which uses Response.Redirect instead of Server.Transfer, doesn't have any problem redirecting to a page in a different folder as is shown in Figure 4.
Figure 4. The links on this page work fine even though the page is located in a different folder than the original page because we used Response.Redirect instead of Server.Transfer.
If you need to redirect users to a page in a different folder, you should use Response.Redirect.
Server.Execute
Another new Server method introduced by ASP 3.0 is Server.Execute. Use Server.Execute to run a chunk of ASP code on another page, returning to the original page when the code is done executing. In many ways, Server.Execute serves a similar purpose to server-side includes. However, because Server.Execute is an ASP method rather than an HTML comment, you can use it to conditionally execute scripts and avoid including huge include files. Server-side includes are executed prior to any ASP code and thus can't be executed conditionally.
Let's illustrate how Server.Execute works with an example. The following hyperlinks appear on the Customer1.asp page:
<A HREF="customer2.asp?type=old">Existing Customers Click Here</A>
</P>
<P>
<A HREF="customer2.asp?type=new">New Customers Click Here</A>
Both hyperlinks on Customer1.asp point to a second page, Customer2.asp, passing it a querystring value of type=old or type=new. Customer2.asp contains the following code, which conditionally executes code on NewCust.asp or OldCust.asp based on the value of the "type" query string:
<%@ Language=VBScript %>
<HTML>
<HEAD>
</HEAD>
<BODY>
<%
If Request.QueryString("type")="new" Then
Server.Execute("NewCust.asp")
Else
Server.Execute("OldCust.asp")
End If
Response.Write("<P><BIG>Whether you are a new or existing " & _
"customer, we are certain that you will appreciate the attention " & _
"that Conglomerated Conglomerates gives to you, our esteemed " & _
"customer and partner.</BIG></P>")
%>
</BODY>
</HTML>
In this trivial example, the code in NewCust.asp and OldCust.asp merely executes a few Response.Writes, but you can execute any ASP code. What's so nice about Server.Execute is that the ASP engine parses the code in the executed page only if the Server.Execute statement is executed.
One drawback to Server.Execute is that it can't call a particular procedure on the included page. Server.Execute starts running code at the top of the executed page and continues running the code until the executed page ends, at which point it returns to the original page. Another potential drawback with Server.Execute is that any page-scope variables are not shared between the original page and the executed page. With server-side includes this isn't an issue because the include file code is incorporated into the original page before it is executed. Regardless, there are many situations where using Server.Execute is a better choice than using server-side includes.
Summary
In this article, you learned about the new ASP 3.0 Server methods: Transfer and Execute. In many cases, you can improve the performance of your Web site by using these new methods. However, as I hope I have demonstrated in this article, there at least some situations where you are better off using Response.Redirect rather than Server.Transfer and server-side includes instead of Server.Execute.
About The Author
Paul Litwin is the CEO of Litwin Consulting. He is the author of numerous articles and several books, including the Access 2000 Developer's Handbook. Paul is currently working on ASP.NET for Developers with coauthor Mike Amundsen. He travels around the U.S. training developers and has authored courseware for AppDev's Active Server Pages and Visual InterDev, and created Access classes and CD and video seminars. Paul is a regular speaker at industry conferences and is the Conference Chair for the ASP Connections conference (www.asp-connections.com). You can reach Paul at plitwin@mcwtech.com.
|
