WindowsServer具有可靠性、可用性、可伸縮性和安全性，這使其成為高度可靠的平臺。也因?yàn)樗�操作的簡�?使用瀏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。雖然這種方式被廣泛接受，但它并不能保證不出錯。一個(gè)確認(rèn)的微軟IIS問題就是在處理大于48K的上傳文件時(shí)會出現(xiàn)一個(gè)超時(shí)報(bào)錯。有時(shí)這只是一次上傳的失敗，但其它時(shí)候這會讓瀏覽器進(jìn)入一個(gè)不停嘗試重新發(fā)送數(shù)據(jù)的死循環(huán)。因?yàn)閷τ跒g覽器來說，沒有一種針對這種特定情況的標(biāo)準(zhǔn)響應(yīng)。

　　這種掛起的原因是IIS使用一種如ASP的應(yīng)用程序來處理客戶端數(shù)據(jù)的上傳。當(dāng)客戶端開始提交數(shù)據(jù)時(shí)，IIS將第一個(gè)48K的數(shù)據(jù)讀入緩沖區(qū)，然后將其傳遞給應(yīng)用程序進(jìn)行處理。任何超出這48K的數(shù)據(jù)會處于等待狀態(tài)直到應(yīng)用程序請求傳輸，通常通過類似Request.BinaryRead(Request.TotalBytes)的命令來執(zhí)行。如果應(yīng)用程序沒有請求，這些數(shù)據(jù)則處于等待連接狀態(tài)。這是一個(gè)典型的413報(bào)錯：請求實(shí)體過大。

　　通常，按照上述規(guī)則進(jìn)行良好的編碼可以避免此類問題，但某些情況下可能需要使用特定的屬性設(shè)置。例如，如果你的某個(gè)站點(diǎn)的上傳是由第三方的ISAPI擴(kuò)展來處理的，它沒有遵循這種做法，此時(shí)就需要進(jìn)行一些調(diào)整來克服48K的限制。這個(gè)限制不是一成不變的，它通過一個(gè)名為UploadReadAheadSize的IIS元數(shù)據(jù)(metabase)屬性來定義。默認(rèn)值為49152K，最高可以設(shè)為4GB。如果需要的話，你可以對一個(gè)單獨(dú)的站點(diǎn)進(jìn)行設(shè)置也可以設(shè)定整個(gè)IIS服務(wù)。

　　這可能不是唯一需要設(shè)置的屬性。你可能還需要修改maxRequestLength(在IIS6)或maxAllowedContentLength(在IIS7 +)的屬性值來允許大型數(shù)據(jù)的上傳，盡管它們的默認(rèn)值也較大。

　　在某些情況下，將UploadReadAheadSize的值設(shè)為零會很有幫助。這會強(qiáng)制IIS將提交的內(nèi)容直接流向ISAPI擴(kuò)展應(yīng)用來處理該請求。這可能是在解決這個(gè)問題時(shí)首先值得嘗試的方法，但是你也應(yīng)該注意到關(guān)閉IIS應(yīng)用程序(不處理預(yù)讀緩沖區(qū))可能帶來的副作用。

　　最后，請記住，增加UploadReadAheadSize的值會產(chǎn)生一個(gè)攻擊面。如果這個(gè)值設(shè)置得很高，并且有人想利用通過上傳文件來耗費(fèi)帶寬的方式攻擊你的系統(tǒng)，他們將很容易得手。為了避免攻擊，使用一個(gè)能夠體現(xiàn)用戶實(shí)際使用的值，并盡可能地堅(jiān)持使用身份驗(yàn)證的方式，以確保上傳者的身份值得信賴。