許多網(wǎng)站都是通過Web瀏覽器讓用戶直接上傳內(nèi)容，但是這種方式缺乏用戶與遠(yuǎn)端服務(wù)器之間的交互性，從而讓他們的互動(dòng)變得不那么容易。首先，在上傳過程中基本沒有什么反饋，有時(shí)在經(jīng)歷了漫長的等待后得到的唯一反饋卻是一個(gè)討厭的報(bào)錯(cuò)。

盡管如此，使用瀏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。因?yàn)橛脩舾矚g它的簡便，而不是費(fèi)勁的去使用文件傳輸協(xié)議（FTP）的工具。

雖然這種方式被廣泛接受，但它并不能保證不出錯(cuò)。一個(gè)確認(rèn)的微軟IIS問題就是在處理大于48K的上傳文件時(shí)會(huì)出現(xiàn)一個(gè)超時(shí)報(bào)錯(cuò)。有時(shí)這只是一次上傳的失敗，但其它時(shí)候這會(huì)讓瀏覽器進(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ù)會(huì)處于等待狀態(tài)直到應(yīng)用程序請求傳輸，通常通過類似Request.BinaryRead（Request.TotalBytes）的命令來執(zhí)行。如果應(yīng)用程序沒有請求，這些數(shù)據(jù)則處于等待連接狀態(tài)。這是一個(gè)典型的413報(bào)錯(cuò)：請求實(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è)為零會(huì)很有幫助。這會(huì)強(qiáng)制IIS將提交的內(nèi)容直接流向ISAPI擴(kuò)展應(yīng)用來處理該請求。這可能是在解決這個(gè)問題時(shí)首先值得嘗試的方法，但是你也應(yīng)該注意到關(guān)閉IIS應(yīng)用程序（不處理預(yù)讀緩沖區(qū)）可能帶來的副作用。

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