許多網站都是通過Web瀏覽器讓用戶直接上傳內容，但是這種方式缺乏用戶與遠端服務器之間的交互性，從而讓他們的互動變得不那么容易。首先，在上傳過程中基本沒有什么反饋，有時在經歷了漫長的等待后得到的唯一反饋卻是一個討厭的報錯。
    盡管如此，使用瀏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。因為用戶更喜歡它的簡便，而不是費勁的去使用文件傳輸協議（FTP）的工具。
    雖然這種方式被廣泛接受，但它并不能保證不出錯。一個確認的微軟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的值會產生一個攻擊面。如果這個值設置得很高，并且有人想利用通過上傳文件來耗費帶寬的方式攻擊你的系統，他們將很容易得手。為了避免攻擊，使用一個能夠體現用戶實際使用的值，并盡可能地堅持使用身份驗證的方式，以確保上傳者的身份值得信賴。

關鍵字：IIS、服務器