許多網(wǎng)站都是通過Web瀏覽器讓用戶直接上傳內(nèi)容，但是這種方式缺乏用戶與遠端服務(wù)器之間的交互性，從而讓他們的互動變得不那么容易。首先，在上傳過程中基本沒有什么反饋，有時在經(jīng)歷了漫長的等待后得到的唯一反饋卻是一個討厭的報錯。
    盡管如此，使用瀏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。因為用戶更喜歡它的簡便，而不是費勁的去使用文件傳輸協(xié)議（FTP）的工具。
    雖然這種方式被廣泛接受，但它并不能保證不出錯。一個確認的微軟IIS問題就是在處理大于48K的上傳文件時會出現(xiàn)一個超時報錯。有時這只是一次上傳的失敗，但其它時候這會讓瀏覽器進入一個不停嘗試重新發(fā)送數(shù)據(jù)的死循環(huán)。因為對于瀏覽器來說，沒有一種針對這種特定情況的標準響應(yīng)。
    這種掛起的原因是IIS使用一種如ASP的應(yīng)用程序來處理客戶端數(shù)據(jù)的上傳。當(dāng)客戶端開始提交數(shù)據(jù)時，IIS將第一個48K的數(shù)據(jù)讀入緩沖區(qū)，然后將其傳遞給應(yīng)用程序進行處理。任何超出這48K的數(shù)據(jù)會處于等待狀態(tài)直到應(yīng)用程序請求傳輸，通常通過類似Request.BinaryRead（Request.TotalBytes）的命令來執(zhí)行。如果應(yīng)用程序沒有請求，這些數(shù)據(jù)則處于等待連接狀態(tài)。這是一個典型的413報錯：請求實體過大。
    通常，按照上述規(guī)則進行良好的編碼可以避免此類問題，但某些情況下可能需要使用特定的屬性設(shè)置。例如，如果你的某個站點的上傳是由第三方的ISAPI擴展來處理的，它沒有遵循這種做法，此時就需要進行一些調(diào)整來克服48K的限制。這個限制不是一成不變的，它通過一個名為UploadReadAheadSize的IIS元數(shù)據(jù)（metabase）屬性來定義。默認值為49152K，最高可以設(shè)為4GB。如果需要的話，你可以對一個單獨的站點進行設(shè)置也可以設(shè)定整個IIS服務(wù)。
    這可能不是唯一需要設(shè)置的屬性。你可能還需要修改maxRequestLength（在IIS6）或maxAllowedContentLength（在IIS7 +）的屬性值來允許大型數(shù)據(jù)的上傳，盡管它們的默認值也較大。
    在某些情況下，將UploadReadAheadSize的值設(shè)為零會很有幫助。這會強制IIS將提交的內(nèi)容直接流向ISAPI擴展應(yīng)用來處理該請求。這可能是在解決這個問題時首先值得嘗試的方法，但是你也應(yīng)該注意到關(guān)閉IIS應(yīng)用程序（不處理預(yù)讀緩沖區(qū)）可能帶來的副作用。
    最后，請記住，增加UploadReadAheadSize的值會產(chǎn)生一個攻擊面。如果這個值設(shè)置得很高，并且有人想利用通過上傳文件來耗費帶寬的方式攻擊你的系統(tǒng)，他們將很容易得手。為了避免攻擊，使用一個能夠體現(xiàn)用戶實際使用的值，并盡可能地堅持使用身份驗證的方式，以確保上傳者的身份值得信賴。

關(guān)鍵字：IIS、服務(wù)器