Programming | Advanced 4.3.3 to perform other web pages
One of the new features of ASP 3.0 and IIS 5.0 is the introduction of the concept of programmable server side orientation (server-side redirection). This means that the control and execution of a Web page can be transferred to another page without the need to use the Response.rdedirect method on the client.
1. Problems with client redirection
ASP programmers typically use the Response.Redirect statement to load a page into the currently executing Web page. However, many people do not realize that this statement does not automatically cause the server to mount and execute the new Web page immediately. What it really does is add an HTTP redirect header (redirection header) to the output stream sent to the customer by the Web server. This header is as follows:
http/1.1 302 Object Moved
Location newpage.asp
In this header, the standard HTTP state information "302 Object moved" informs the browser that the requested resource has moved. The location header provides the corresponding Web page address. Of course, the address is not necessarily true, and what is being done is "spoofing" the browser so that the browser thinks it can find the Web page in another location. What actually happens is that the server executes the requested page, but notifies the browser that the page that is needed has moved. This is why the redirect method must be executed before the content of any page is sent to the browser.
When a browser accepts "302 Object moved" information, interrupts the current request and sends a new request for the Web page specified in the location value. This works in the same way that a meta http-equiv tag is used in the <HEAD> section of a Web page, and the preceding HTTP header can also be written as:
<meta http-equiv= "REFRESH" content= "0; Url=newpage.asp ">
So redirects actually occur on the client side, not on the server. If a proxy server is in use on this connected client, it may cause false messages to be displayed. This is why, when using Response.Redirect, the "the object you requested has been moved and can is found here" message is often displayed on the client, and using buffering correctly usually prevents this problem.
When using Response.Redirect in IIS 4.0 or earlier, you should turn on buffering at the beginning of the ASP Web page, and then call Response.Clear before executing the Response.Redirect method. Of course, the default state of Web page buffering in ASP 3.0 is open, so this is no problem. As long as you use response.clear before executing the statement, the previously generated output will not be sent to the customer.
2. Server-side redirection in ASP 3.0
In almost all cases, in ASP 3.0 and IIS 5.0, you can avoid using client redirection by using the two new server object methods execute and transfer. These two methods let control go immediately to another page, which can be an ASP page or any other resource, such as an HTTP Web page, a compressed file, or another type of file.
The difference between them is that the Execute method "invokes" another Web page that is very similar to calling a subroutine or function in script code. When another Web page or resource has been executed or passed to the client, control returns to the next statement of the statement that called the Execute method in the original Web page and continues execution. When using the transfer method, the control no longer returns to the original page, and the execution stops at the end of the page or resource to which the control is transferred.
The environment for the current Web page is also sent to the destination Web page or resource, so these two methods are more useful. The Web page environment contains the values of all the variables in the original ASP object, such as the collection of request, response, and session objects, and all their properties. The environment for the Application object is routed even if the page is not in the same virtual application.
The result is that the browser thinks it's still receiving the original page, and it doesn't know what the server is doing. The browser's address bar always displays the same URL, and the back, forward, and Refresh buttons work properly. This is usually not the case when using client redirection, especially when using HTML meta elements.
The environment that is transferred to the new page or resource includes all existing transaction states (transaction state). The environment for the current Web page is encapsulated with an ASP's ObjectContext object (discussed in chapter 1th). If you need to make this object part of an ongoing transaction, you can use the object in the destination page of the transfer control.
(1) Use of the Execute and transfer methods of the server object
In the previous example page, you can experiment with the Excute and transfer methods. The page contains another file name another_page.asp that has been provided in the example, which serves as the default parameter value for both methods, as shown in Figure 4-13:
Figure 4-13 Screen using the Execute and Transfer methods
Click the buttons for the Server.Execute and Server.Transfer methods to submit to this form and reload the form. At the top of this page, the script code looks at which button is clicked. If it is a cmdexecute or Cmdtransfer button, the path to the current page is written to the output stream, the corresponding method is called, and the value in the text box associated with the button is passed, and then the path to the current page is written to the output stream.
...
If Len (Request.Form ("Cmdexecute")) Then
strpath = Request.Form ("Txtexecpath")
Response.Write "Currently executing the page: <B>" _
& Request.ServerVariables ("Script_name") & "</B><BR>"
Server.Execute (strpath)
Response.Write "Currently executing the page: <B>" _
& Request.ServerVariables ("Script_name") & "</B><BR>"
End If
If Len (Request.Form ("Cmdtransfer")) Then
strpath = Request.Form ("Txttransferpath")
Response.Write "Currently executing the page: <B>" _
& Request.ServerVariables ("Script_name") & "</B><BR>"
Server.Transfer (strpath)
End If
...
When you click the Server.excute Method's button, you see the path to the current page, which is created and displayed by the first Response.Write statement in the preceding code. What follows is some output from the executed Web page (another_page.asp). This is followed by the output of the second Response.Write statement, which shows that the control is back to the original page, as shown in Figure 4-14:
Figure 4-14 Server.excute Method Demo
The paragraph between the two horizontal lines of the page (showing the currently executing page as show_server.asp) comes from the original page. The following paragraphs come from the executed page another_page.asp. Here is the complete code for the page:
<%@ Language=vbscript%>
<HR>
Currently executing the page: <B>another_page.asp</B><BR>
However the value of <b>request.servervariables ("Script_name") </B> is still <BR>
<b><% = Request.ServerVariables ("Script_name")%></b>
Because the <B>Request</B> collections hold<br>
The same values as they had in the page that executed thi
