先看如下 web.config 的代碼：
<compilation debug="true" targetFramework="4.0" />
<httpRuntime requestValidationMode="2.0" />
<pages validateRequest="false" > </pages >
</system.web >
validateRequest 這句我們知道是關閉驗證，也就是說提交帶標簽，比如 <strong>粗體</strong> 這樣的值時，ASP.NET 不會報錯。
但在 4.0 中還多了一個 requestValidationMode，這是什么意思呢？
requestValidationMode 有兩個值：
- 2.0僅對網頁啟用請求驗證。是啟用還是關閉取決於 validateRequest。
- 4.0 默認值。任何 HTTP 請求都會啟用請求驗證，也就是說不光是網頁，還包括 Cookie 等。此時強制啟用，不管 validateRequest 為何值。
由於 requestValidationMode="4.0" 是強制啟用，所以我們會發現在 .NET Framework 4.0 中僅靠設置 validateRequest 是關閉不了請求驗證的，還得將 requestValidationMode 設置為 2.0。
ASP.NET中的請求驗證特性提供了某一等級的保護措施防止XSS攻擊，之前版本的ASP.NET的請求驗證是默認啟動的,但是他緊緊應用於ASP.NET頁面中(.aspx文件和.aspx.cs文件)。
而在ASP.NET4中，請求驗證默認對所有類型的請求啟動，因為它在BeginRequest被調用之前啟動,結果就是對所有資源的請求都要經過請求驗證，而不僅僅在.aspx文件和他們的類文件中,甚至包括web service和自定義的httphandler。同樣，在自定義httpmodules讀取http請求的時候，同樣要經過請求驗證。
上述原因引發的最終結果就是在ASP.NET4中會引發請求錯誤，例如檢測到有潛在危險的Request.Form值等等，為了解決這個問題，可以通過將驗證模式設置為ASP.NET之前的版本。具體步驟是在web.config中加入以下配置：
<httpRuntime requestValidationMode=”2.0″ />
設置了請求模式后，再設置
<system.web>
<pages validaterequest=”false”/>
</system.web>
MVC框架中，在控制方法前加入：
[ValidateInput(false)]屬性。
那么就可以禁止請求驗證了。但是這會引發安全問題，對安全問題的討論請看這里：點擊這里查看
另外還有一種方法就是實現自己的請求驗證類，首先需要在web.config中指定請求驗證類類型：
<httpRuntime requestValidationType=”Globals.CustomRequestValidation”/>
然后實現自己的請求驗證類，這個類必須從RequestValidator類中繼承，具體代碼如下：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Util;
namespace Globals
{
/// <summary>
/// Summary description for CustomRequestValidation
/// </summary>
public class CustomRequestValidation : RequestValidator
{
public CustomRequestValidation() { }
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, outint validationFailureIndex)
{
//block script tags
var idx = value.ToLower().IndexOf(“<script”);
if (idx > -1)
{
validationFailureIndex = idx;
return false;
}
else
{
validationFailureIndex = 0;
return true;
}
}
}
}
IsValidRequestString函數返回true則驗證通過，否則驗證失敗，還會出現文章開頭所說的錯誤消息。此請求驗證類當檢測到<script>標簽時就會出現錯誤，防止腳本注入攻擊等等。
============================================
DW與ACCESS連接字符串本地和遠程
一、在本地“瀏覽”調試網站時的連接方法
在 DW 或本地的 IIS 服務器下瀏覽、調試網站訪問數據庫時，自定義連接字符串中使用數據庫的絕對路徑，操作如下：
打開 DW，建好站點，打開所需網頁，例如主頁文件 index.asp，在彈出的“自定義連接字符串”對話框中“連接名稱”欄填寫自定義的名稱（為了養成好的編程習慣，最好名稱前加上 conn 前綴，表明這是一個數據庫的連接名稱，例如本來你想起的連接名稱為 test，加上 conn 前綴后的連接名稱為 conntest）。在“連接字符串”欄中填寫：
"Driver={Microsoft Access Driver (*.mdb)};DBQ=你的數據庫的絕對路徑"
把本文開始處假定的具體參數代進去就是：
"Driver={Microsoft Access Driver (*.mdb)};DBQ=F:\try\data\aaa.mdb"
一定要注意：Driver 和 (*.mdb) 之間有個空格，不要寫錯了！寫錯了不能通過“測試”，當然也連接不上數據庫。上面連接字符串兩端的雙引號在輸入時可以省略，DW 會自動為你補上的。
在“Dreamweaver 應連接”項中，應選擇“使用此計算機上的驅動程序”。填寫完畢后，點擊右邊的[測試]按鈕，如果操作沒有問題的話，就會彈出“成功創建連接腳本”的信息牌。點擊[確定]完成連接的創建。
此時回到 DW 的“應用程序”面板中的[數據庫]，可以看到我們創建的數據庫連接已經生效，並能查看數據庫的結構和相關信息。
在數據庫的數據表圖標上單擊右鍵，選擇“查看數據”，可以查看到該數據表中的詳細內容。
在“文件”面板中，我們可以看到 DW 自動生成了一個 Connections 的文件夾，其中包含了一個以我們剛才自定的連接名稱 conntest 命名的 asp 文件，這個就是保存連接字符串的地方。之后的綁定記錄集操作因不是本文主題，故略去。
到此，與數據庫連接的網頁在本地 IIS 服務器和 DW 下可以正常訪問數據庫進行“瀏覽”了，但不能保證你的網站上傳到遠程服務器的空間后也能正常。
二、讓數據庫的連接同時適應本地和遠程服務器環境
我們在連接中使用了數據庫的絕對路徑 F:\try\data\aaa.mdb，而當我們把網站上傳到遠程服務器后，服務器上你的數據庫的絕對路徑可能和本地路徑不一樣，相關程序就會出錯。為了避免這種情況，我們應在程序中使用相對路徑。
在 DW 下雙擊打開連接文件（本文中是 conntest.asp），切換到[代碼]編輯方式，找到其中的這一行：
MM_conntest_STRING = "Driver={Microsoft Access Driver (*.mdb)};DBQ=F:\try\data\aaa.mdb"
在這一行前加一個單引號“'”把它變成注釋行，然后在下面新建一行，輸入如下代碼：
MM_conntest_STRING = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="&Server.Mappath("data/aaa.mdb")
很多人也許會奇怪，為什么我們不在創建連接時就使用相對路徑呢？其實這是有原因的。在 DW 中的連接字符串中只能使用絕對路徑，而 DW 有個特點，就是檢測連接文件（這里是 conntest.asp）時，會連注釋（以單引號開頭的行）一起解釋、執行，在 DW 中“瀏覽”網頁、執行數據庫的連接時，只認第一個出現的連接字符串，而不管它前面是否有作為注釋標記的單引號；而在遠程 IIS 服務器中解釋文件時會忽略掉注釋（即繞過有注釋標記的行），執行上面我們另加的第二個連接字符串。根據這個特點，我們就實現了在本地 IIS 服務器和 DW 下調試程序使用絕對路徑，在遠程服務器上瀏覽時使用相對路徑定位數據庫，使得網站與數據庫的連接在網站存放地點不同的情況下能“自動”隨機應變，暢通無阻。