WindowsServer具有可靠性、可用性、可伸縮性和安全性，這使其成為高度可靠的平台。也因為它操作的簡便,使用浏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。雖然這種方式被廣泛接受，但它並不能保證不出錯。一個確認的微軟IIS問題就是在處理大於48K的上傳文件時會出現一個超時報錯。有時這只是一次上傳的失敗，但其它時候這會讓浏覽器進入一個不停嘗試重新發送數據的死循環。因為對於浏覽器來說，沒有一種針對這種特定情況的標准響應。
這種掛起的原因是IIS使用一種如ASP的應用程序來處理客戶端數據的上傳。當客戶端開始提交數據時，IIS將第一個48K的數據讀入緩沖區，然後將其傳遞給應用程序進行處理。任何超出這48K的數據會處於等待狀態直到應用程序請求傳輸，通常通過類似Request.BinaryRead(Request.TotalBytes)的命令來執行。如果應用程序沒有請求，這些數據則處於等待連接狀態。這是一個典型的413報錯：請求實體過大。
通常，按照上述規則進行良好的編碼可以避免此類問題，但某些情況下可能需要使用特定的屬性設置。例如，如果你的某個站點的上傳是由第三方的ISAPI擴展來處理的，它沒有遵循這種做法，此時就需要進行一些調整來克服48K的限制。這個限制不是一成不變的，它通過一個名為UploadReadAheadSize的IIS元數據(metabase)屬性來定義。默認值為49152K，最高可以設為4GB。如果需要的話，你可以對一個單獨的站點進行設置也可以設定整個IIS服務。
這可能不是唯一需要設置的屬性。你可能還需要修改maxRequestLength(在IIS6)或maxAllowedContentLength(在IIS7 +)的屬性值來允許大型數據的上傳，盡管它們的默認值也較大。
在某些情況下，將UploadReadAheadSize的值設為零會很有幫助。這會強制IIS將提交的內容直接流向ISAPI擴展應用來處理該請求。這可能是在解決這個問題時首先值得嘗試的方法，但是你也應該注意到關閉IIS應用程序(不處理預讀緩沖區)可能帶來的副作用。
最後，請記住，增加UploadReadAheadSize的值會產生一個攻擊面。如果這個值設置得很高，並且有人想利用通過上傳文件來耗費帶寬的方式攻擊你的系統，他們將很容易得手。為了避免攻擊，使用一個能夠體現用戶實際使用的值，並盡可能地堅持使用身份驗證的方式，以確保上傳者的身份值得信賴。
