IIS 伺服器端網頁重導向：Server.Transfer 與 Server.Execute 深度解析

在傳統 ASP 開發中，Response.Redirect 是最常見的頁面跳轉方式，但它屬於客戶端重導向：伺服器回傳 HTTP 302 狀態碼與新 URL，瀏覽器再發起第二次請求。這不僅增加網路延遲，還會導致 QueryString 參數遺失、Session 在某些情境下中斷等問題。

IIS 5.0 引入的兩大伺服器端重導向方法

IIS 5.0（Windows 2000）提供 Server.Transfer 與 Server.Execute，兩者均在伺服器端完成處理，瀏覽器 URL 不變、無額外往返，可節省頻寬並保留原頁面的 Request、Response、Session、Application 等內建物件內容。

1. Server.Transfer ——「轉交不回」

<%
Response.Write "File 1 Header<br>"
Server.Transfer "file2.asp"
Response.Write "File 1 Footer<br>"  ' 永不執行
%>

行為： 遇到 Transfer 即終止當前頁面執行，控制權永久移交目標頁面。
輸出結果： File 1 Header + file2.asp 的全部輸出。

2. Server.Execute ——「子程式式調用」

<%
Response.Write "File 1 Header<br>"
Server.Execute "file2.asp"
Response.Write "File 1 Footer<br>"  ' 繼續執行
%>

行為： 暫停當前頁面，執行目標頁面，完成後返回繼續執行後續程式碼。
輸出結果： File 1 Header + file2.asp 輸出 + File 1 Footer。

效能與記憶體考量

• 兩者皆需在伺服器端維護呼叫端的執行狀態，會消耗額外記憶體。
• 高併發下，大量 Execute 可能導致堆疊深度過大，建議評估改用 Server.Transfer 或重構為 User Control / Master Page 架構（ASP.NET）。
• 傳遞大量資料時，優先考慮 Session、Application 或 Context.Items（ASP.NET），避免 QueryString 長度限制。

適用場景速查表

注意： ASP.NET 建議改用 Server.TransferRequest（整合管線模式）或 HttpContext.RewritePath，傳統 Transfer/Execute 在整合模式下可能引發模組事件重複觸發問題。