4.3.3 執行其他的網頁
ASP 3.0和IIS 5.0的新特性之一就是引入了可編程的服務器端重定向（server-side redirection）的概念。這意味著，可以把一個網頁的控制和執行轉到另外一個網頁，而不需要在客戶端使用Response.Rdedirect方法。
1． 客戶端重定向帶來的問題
ASP編程人員通常使用Response.Redirect語句把一個頁面載入到當前正在執行的網頁。然而，許多人沒有意識到這條語句不會自動地使服務器立即裝入和執行新的網頁。其真正做的是把一個HTTP重定向報頭（redirection header）增加到由Web服務器發送給客戶的輸出流中。這個報頭如下：
HTTP/1.1 302 Object Moved
Location newpage.ASP
在這個報頭中的標准HTTP狀態信息“302 Object Moved”，告知浏覽器所要求的資源已經發生移動。Location報頭提供相應的網頁地址。當然這個地址不一定是真實的，現在正在做的事情就是“欺騙”浏覽器，使浏覽器認為可在另一個位置上找到所需要的網頁。實際發生的是，服務器將執行所請求的網頁，但是通知浏覽器需要的網頁已經發生移動。這就是在發送任何頁面的內容到浏覽器之前必須執行Redirect方法的原因。
當一個浏覽器接受到“302 Object Moved”信息時，中斷當前的請求並為Location值中指定的網頁發送一個新的請求。這與在網頁的<HEAD>段使用一個META HTTP-EQUIV標記時的工作方式相同，前面給出的HTTP報頭還可寫為：
<META HTTP-EQUIV=”REFRESH” CONTENT=”0;URL=newpage.ASP”>
因此重定向實際上發生在客戶機端，而不是在服務器上。如果在這個連接的客戶端有一個代理服務器在使用的話，可能會引起顯示虛假消息。這就是在使用Response.Redirect時，“The object you requested has been moved and can be found here”消息經常在客戶機上顯示的原因，正確地使用緩沖通常可以防止這個問題。
在IIS 4.0或更早的版本中使用Response.Redirect時，應該在ASP網頁的開頭打開緩沖，然後在執行Response.Redirect方法之前調用Response.Clear。當然，在ASP 3.0中網頁緩沖的缺省狀態為打開，因此這不成問題。只要在執行該語句之前使用Response.Clear，以前產生的輸出將不會發送給客戶。
2． 在ASP 3.0中服務器端的重定向
在ASP 3.0和IIS 5.0中，在幾乎所有情況下，通過使用兩個新的Server對象方法Execute和Transfer，可以避免使用客戶端重定向。這兩個方法使控制立即轉到另一個網頁，該網頁可以是一個ASP網頁或者是任何其他的資源，例如一個HTTP網頁、壓縮文件或其他類型的文件。
它們之間的不同之處是：Execute方法“調用”另一個的網頁，與在腳本代碼中調用一個子程序或函數非常相似。當另一個網頁或資源已經執行完畢或傳送到客戶端時，控制返回到原網頁中調用Execute方法的語句的下一條語句，並繼續執行。而使用Transfer方法時，控制不再返回到原頁面中，在控制傳送到的網頁或資源的末尾處，執行過程停止。
當前網頁的環境也傳送給了目標網頁或資源，因此這兩個方法更有用。網頁環境包含了原有的ASP對象中的所有變量的值，例如Request、Response和session對象的集合以及它們的所有屬性。即使該網頁不在同一個虛擬應用程序中，也將傳送application對象的環境。
結果是浏覽器認為它仍在接收原先的頁面，它並不了解服務器所做的事情。浏覽器的地址欄一直顯示相同的URL，並且Back、Forward和Refresh按鈕正常地工作。在使用客戶端重定向時，尤其是使用Html META元素時，情況通常不是這樣的。
傳送到新的頁面或資源的環境包括所有現存的事務狀態（transaction state）。當前網頁的環境用ASP的ObjectContext對象（在第1章中已經討論過）進行封裝。如果需要將這個對象作為一個正在進行的事務的一部分，可以在傳送控制的目的頁面中使用這個對象。
(1) Server對象的Execute和Transfer方法的使用
在前面的示例頁面中，可以試驗使用Excute和Transfer方法。該頁面包含了在示例中已經提供的另一個文件名字another_page.ASP，它作為這兩個方法的缺省參數值，如圖4-13所示：
圖4-13 使用Execute和Transfer方法的屏幕
單擊Server.Execute和Server.Transfer方法的按鈕，提交到此窗體並重新裝載該窗體。在這個頁面頂部的腳本代碼查看是哪個按扭被單擊。如果是cmdExecute或cmdTransfer按鈕，則把當前網頁的路徑寫入到輸出流中，然後調用相應的方法，並傳送與該按鈕相聯系的文本框中的值，然後再把當前頁面的路徑寫到輸出流中。
…
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
…
當單擊Server.Excute方法的按鈕時，會看到當前頁面的路徑，這是由上面代碼中的第一條Response.Write語句創建並顯示的。後面接著的內容是來自被執行的網頁（another_page.ASP）的一些輸出內容。在這之後是第二個Response.Write語句的輸出內容，這表明控制又回到了原先的網頁，屏幕如圖4-14所示：
圖4-14 Server.Excute方法的演示
頁面的兩條水平線之間的段落（顯示當前執行的網頁為show_server.asp）來自原先的網頁。在接下來的段落來自被執行的網頁another_page.ASP。下面是該頁面的完整代碼：
<%@ 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 this one.<BR>
<FORM ACTION="<% = Request.ServerVariables("HTTP_REFERER") %>" METHOD="POST">
<INPUT TYPE="SUBMIT" NAME="cmdOK" VALUE=" ">
Return to the PRevious page<P>
</FORM>
<HR>
注意，該頁面執行時，不能使用Request.ServerVariables(“SCRIPT_NAME”)獲取它的路徑，因為環境仍然是原網頁的。我們不得不把頁面名作為文本寫入，因為實在沒有辦法可以從ASP環境中直接獲取。
這裡包括了一個返回前一個網頁的按鈕的原因是，通過在主網頁中單擊相對應的按鈕，可以使用Server.Transfer方法調用這個頁面。這次看到了完全相同的輸出，只是沒有第二次路徑輸出，因為是“傳送”這個頁面而不是“執行”該頁面，所以控制不會回傳給原先的網頁，如圖4-15所示：
圖4-15 Server.Transfer的演示
(2) 從ASP執行SSI網頁
目前有了一個方法，如果需要的話可在ASP網頁中成功地使用SSI指令。雖然這種要求不常出現，但可實現。過去的問題是，由於在SSI網頁（文件擴展名是.stm、.sHtml和.shtm）中不能包含ASP代碼，所以程序不能“無縫”地重定向回到原先的網頁，必須增加一個按鈕或鏈接，以裝載原先的或另外的ASP網頁。
現在，由於有了Server.Execute方法，可以執行一個SSI網頁並且將控制自動返回到原先的網頁，客戶端意識不到這些過程正在進行。客戶端只是看到原先的ASP網頁和執行結果。來自於SSI網頁的任何輸出都“無縫”地插入到流中。當然，如果在SSI網頁完成後，不想使原先的網頁繼續執行，可以使用Server.Transfer方法。
為了看到這個技術的執行，把前面使用過的CGI-SSI例子網頁的虛擬路徑輸入到Server.Excute方法（或Server.Transfer方法）的文本框中。這個路徑是“../ssi_cgi/ssi_cgi.stm”。在單擊按鈕對Execute或Transfer方法進行調用以後，將看到.stm網頁已經執行，其中有SSI指令的結果。在來自ssi_CGI.stm的內容之後出現的是原先的網頁的其余部分，雖然在圖4-16中看不到，但可通過滾動條看到該內容。
圖4-16 執行Server.Excute方法後的屏幕
3． SSI #exec指令的不足
遺憾的是Execute和Transfer方法一般不能與SSI的#exec指令一起工作，因為包含這個指令的.stm網頁會在調用它的ASP網頁的環境中運行。在大多數情況下，它需要運行於直接引用該網頁的一個獨立的環境中。
存在這樣的限制真是遺憾，如果沒有這種限制，我們通過Server.Execute執行的網頁可以“不可見地”包含來自於ASP網頁的#exec指令。對前面的通過net stop和net start命令停止和啟動Indexing Service的示例來說，它可能是一種理想的解決方案。
但是，我們必須求助於老的和已經驗證的方法。當用戶單擊一個按鈕時，簡單地使用Response.Redirect方法來打開相關的網頁：
<%
‘Look for a command sent from the FORM section buttons
If Len(Request.Form(“cmdStop”)) Then
Response.Redirect(“exec/stop_cisvc.stm”)
End If
If Len(Request.Form(“cmdStart”)) Then
Response.Redirect(“exec/start_cisvc.stm”)
End If
%>
可以試著把使用#exec指令的一個SSI網頁的虛擬路徑輸入到示例頁面的Server.Execute和Server.Transfer方法的文本框中。前面使用過的#exec示例的虛擬路徑是“../ssi_cgi/exe/start_cisvc.stm”和“../ssi_CGI/exec/stop_cisvc.stm”。
