ASP 3.0對ASP 2.0的改進

下面的一些特征是從2.0版本中改進或升級來的。

1、 緩沖缺省為打開狀態(tài)
ASP提供可選的輸出緩沖。從IIS 4.0開始，這使得腳本執(zhí)行得更快，并提供對流向瀏覽器的輸出的控制能力。在ASP 3.0這個改進的性能通過改變Reponse.Buffer屬性的缺省設(shè)置為True而反映出來。缺省狀態(tài)下緩沖是打開的，這意味著最終輸出只有在進程完成時，或腳本調(diào)用Response.Flush或Response.End方法時，才送至客戶端。
注意，可以通過設(shè)置Response.Buffer屬性為False，關(guān)閉緩沖。只有這樣，才能發(fā)送XML格式化輸出給客戶端，讓XML分析器在收到輸出后開始工作。也可以使用Response.Flush發(fā)送大頁面的一部分，這樣使用戶可以很快看到部分輸出。

2、 Response.IsClientConnected的變化
Response.IsClientConnected屬性可以在沒有任何內(nèi)容發(fā)送給客戶端的情況下被讀取到。在ASP 2.0中，這只在至少有一部分內(nèi)容被發(fā)送后才能返回準確的信息。這一改進解決了IIS必須響應(yīng)每個客戶的請求（即使客戶可能已經(jīng)轉(zhuǎn)移到另一個頁面或站點）的問題。同時如客戶在3秒內(nèi)沒有再連接，服務(wù)器上創(chuàng)建的完整的輸出信息將被丟棄。

3、  帶有默認文檔的查詢字符串
假如一個用戶訪問一個站點而不提供所請求頁面的名字，默認的文檔（如存在的話）將被送往客戶端。然而假如他們提供了附在URL后面的查詢字符串，這在早先的ASP版本中是被忽略的，而在IIS 5.0和ASP 3.0中這個查詢字符串將被送到缺省頁面。例如，在一個URL為：http://www.wrox.com/store/的目錄中缺省頁面為default.asp，則下面這兩種情況都將名稱/值對Code=1274送往default.asp頁面：
http://www.wrox.com/store/?code=1274
http://www.wrox.com/store/default.asp?code=1274

4、 服務(wù)器端包含文件的安全性
服務(wù)器端的包含文件常用于一些敏感的信息，如數(shù)據(jù)庫連接字符串或其他訪問細節(jié)。一個虛擬的路徑（即URL而不是完整的物理磁盤文件路徑）可以用來指定這些文件。在這種情況下，早先的ASP版本不核對文件的安全設(shè)置和用戶的證書；換句話說，授權(quán)（驗證后）的用戶和匿名的Web服務(wù)器帳號都沒有與文件的訪問控制列表相比較。在IIS 5.0和ASP 3.0，這些證書將被檢查以防止非授權(quán)訪問。

5、 可配置項移到元數(shù)據(jù)庫中
在IIS 5.0中ProcessorThreadMax和ErrorsToNTLog的注冊項被移到元數(shù)據(jù)庫中，所有有ASP可配置參數(shù)能夠通過Active Directory和Active Directory服務(wù)接口（ADSI）在元數(shù)據(jù)庫中修改。

6、 應(yīng)用程序中的雙線程對象的性能
為了常有多個并發(fā)請求的ASP中獲得最佳性能，組件應(yīng)是雙線程的（Both-Threaded）——即單線程單元（Single Threaded Apartment，STA）和多線程單元（Multi-Threaded Apartment，MTA），并且支持COM Free-Thread Marshaller（FTM）。不支持FTM的雙線程的COM對象假如被存儲在ASP Application狀態(tài)對象中，將導致運行失敗。

7、 更早釋放COM對象
在IIS 5.0中，實例化的對象或組件可更早釋放。在IIS 4.0中，COM對象只有在ASP處理完一個頁面時才能釋放。在IIS 5.0中，假如一個COM對象不使用OnEndPage方法，且對象的引用計數(shù)達到零，則這個對象在處理完成之前就被釋放了。

8、  缺省時ASP允許進程外組件
定制的本地服務(wù)器組件現(xiàn)在可以從IIS中被實例化，而不需要改變數(shù)據(jù)庫的設(shè)置�？刂票镜胤�務(wù)器實例化的元數(shù)據(jù)庫屬性AspAllowOutOfProcComponents缺省值為1，在IIS早期版本為0。

9、  COM對象的安全性
IIS使用了新的由COM+提供的cloaking特性，因此，從ASP實例化的本地服務(wù)器應(yīng)用程序可以運行在原始的客戶的安全環(huán)境中。在早期版本中，安全環(huán)境被指派到本地服務(wù)器COM對象，依賴于調(diào)用進程的身份。

10、缺省時組件運行在進程外
       在ASP早期版本中，所有在ASP頁面環(huán)境中創(chuàng)建的組件缺省時運行在進程內(nèi)。
       為在組件的性能和Web服務(wù)器安全性之間折衷，對于一個虛擬的應(yīng)用程序，可以從Properties對話框中Application Protection的三個選項中選擇：
       · Low（IIS Process）
       這種設(shè)置的ASP虛擬應(yīng)用程序可執(zhí)行文件和組件都運行在Web服務(wù)器可執(zhí)行文件（Inetinfo.exe）的進程（即內(nèi)存空間）中。因此，Web服務(wù)器就有受到可執(zhí)行文件或組件失敗影響的風險，然而這提供了最快的和最少資源的應(yīng)用程序執(zhí)行選項。
       · Medium（Pooled）——這是缺省設(shè)置
       這種設(shè)置的ASP虛擬應(yīng)用程序的所有應(yīng)用程序可執(zhí)行文件和組件都運行在單個共享的DLLHost.exe實例的進程（即內(nèi)存空間）中。這保護了Web服務(wù)器可執(zhí)行文件（Inetinfo.exe）免受任何一個可執(zhí)行文件或組件失敗帶來的風險。然而，可執(zhí)行文件或組件的失敗會引起DLLHost.exe進程失敗，進而所有其他駐留其中的可執(zhí)行文件和組件也會失敗。
       · High（Isolated）
       這種設(shè)置的ASP虛擬應(yīng)用程序的所有應(yīng)用程序可執(zhí)行文件和組件都運行在單個DLLHost.exe實例的進程（即內(nèi)存空間）中，但是每個ASP應(yīng)用程序都有自己的DLLHost.exe實例。DLLHost.exe對應(yīng)用程序而言是獨有的，這保護Web服務(wù)器可執(zhí)行文件免受任何一個可執(zhí)行文件或組件失敗帶來的問題。微軟建議在任何一個Web服務(wù)器上最多駐留10個隔離的虛擬應(yīng)用程序。
       推薦的配置是：在它們自己的進程中運行對于任務(wù)關(guān)鍵的應(yīng)用程序，即High（Isolated）；余下的所有應(yīng)用程序在一個共享的進程中運行，即Medium（Pooled）。也可設(shè)置組成每個虛擬應(yīng)用程序的腳本和組件的執(zhí)行權(quán)限（Execute Permission），三個選項是：
1）    None：在這個虛擬的應(yīng)用程序中不能運行腳本或可執(zhí)行文件。在實際效果上，這提供了一個在必要時快速和簡便地禁止一個應(yīng)用程序的方式。
2）    Scripts only：僅允許腳本文件，諸如ASP、IDC或其他，能夠在這個虛擬應(yīng)用程序中運行，可執(zhí)行文件不能運行。
3）    Scripts and Executables：允許任何腳本和可執(zhí)行文件在這個虛擬應(yīng)用程序中運行。