IIS記事兩則:上傳空間限制(MaxRequestLength) 與 錯誤追蹤紀錄不完整(LOG-FILE-MAX-SIZE-TRUNCATE)

Windows Server 的IIS 有個陳年舊案：系統為了安全與效能考量，會限制上傳檔案的大小。從多年前的4MB大小，演變到在.net framework可自行調整設定。若設的太保守，user上傳檔案超過限制，系統會直接噴錯誤。這靠try-catch會攔不下來，得從該部主機的事件檢視器裡才能觀察的到。

要解決本問題，以Server 2012而言的步驟如下：

(1)首先要改 web.config內的 <system.web> 區段內的httpRuntime設定，在當中增加maxRequestLength屬性(請記得是將語法加到現有那一行內的內容，不是多複製一條貼上。這樣會造成網站不能運作)。
範例中8096的單位是KB。

<system.web>

<httpRuntime targetFramework="4.5" enableVersionHeader="false" maxRequestLength="8096" executionTimeout="300" />

..... 

</system.web>

(2)再者，
在IIS的要求篩選頁面的設定，點選右方藍色小字的 編輯功能設定。
允許的內容上限應比前述步驟一的httpRuntime略大一些。

另外，加上錯誤的處理程序會更好一些。讓Global.asax實作超出可容忍上傳大小的錯誤處理，避免噴出錯誤，而是重導到某個較友善的說明網頁。

protected void Application_BeginRequest(object sender, EventArgs e)

{

    HttpRuntimeSection section = WebConfigurationManager.GetSection("system.web/httpRuntime") as HttpRuntimeSection;

    if (section != null)

    {

        if (Request.ContentLength > (section.MaxRequestLength * 1024))

        {

            Response.Redirect("~/PostedQuotaExceed.aspx");

        }

    }

}

另外一個問題是，新版windows server上的iis 管理人員，多半已經利用錯誤追蹤(Failed Request Tracing) 來捕捉上線環境種種惱人的bug。但有時候很討厭，記錄大到還沒有顯示出錯程式的位置就已經結束，顯示LOG-FILE-MAX-SIZE-TRUNCATE。IIS Trace到紀錄單一檔案的大小上線時，就會停止繼續保留追蹤紀錄。

以前都認為有把功能打開就好，但其實沒有正確設定，這樣豈不等於有記跟沒記一樣?

為了避免記錄做半套，可以依照以下作法精進：

(1)以系統管理員身分啟動命令提示字元

(2)切換到 windows 目錄下的 system32\inetsev

C:\> cd %windir%\System32\inetsrv

appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:1024

按下enter後 系統顯示:

已將設定變更套用至設定認可路徑 "MACHINE/WEBROOT/APPHOST" 中 "MACHINE/WEBROOT/APP

HOST" 的區段 "system.applicationHost/sites"。

這樣就大功告成了。