兩個長度限制問題的分析(來源於專案)
一、問題起因
在某專案釋放後Bug統計的附件《釋放後問題》裡有：
| 問題 | 原因 | 分析 | 備註 |
|
CSV處理時，如果處理的主題數過多，發生URL引數上限的錯誤；<?xml:namespace prefix = u1 /> |
可變長度的引數通過URL方式傳遞，會造成這種潛在的錯誤發生。 |
1、屬於2次發生問題，開發方面沒有及時通過checklist等方式向組員傳達相關注意事項； |
1、作為經驗新增至CheckList中，加強組內共享、檢查的效果； |
|
通過對模組原有GUI狀況確認，進行 |
沒有考慮到POST資料量存在128K的大小限制。 |
這屬於新問題，以前從未遇見過，也沒有進行過大規模的資料量測試 |
已將此類檢查列出CheckList中 |
做為一種經驗積累，這些問題、原因及解決辦法將被列入Checklist，那麼：
第一個問題：URL引數上限的提法準確嗎？上限是多少？
第二個問題：為什麼POST時資料有限制？限制是128K嗎？
二、問題分析
1、第一個：
1）URL不存在引數上限的說法。該問題實際是IE對URL有長度限制的問題。
2）HTTP協議規範也沒有對URL長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制。IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於作業系統的支援。[參1]
3）“可變長度的引數通過URL方式傳遞”實際是說提交表單時使用了GET方法，而不是POST方法。造成這種潛在錯誤的是使用GET方法提交表單資料。因為GET方法將資料放在URL裡傳遞給伺服器處理。
4）注意這個限制是整個URL長度，而不僅僅是你的引數值資料長度。
5）既然是IE對URL長度的限制，那麼不管是GET方法還是POST方法都存在這個限制。
(關於FORM的GET和POST方法具體內容請參考相關資料[參2])
建議：
1）瞭解應用程式所在的環境，如Web應用的瀏覽器、伺服器環境，瞭解其特定的引數限制情況。
2）提交複雜資料儘量使用POST方法。注意FORM不寫method屬性時預設是使用GET方法。
結論(寫入Checklist)：
對使用GET方法提交資料時，在IE環境下，需要考慮URL長度2083位元組的限制。
2、第二個：
1）理論上講，POST是沒有大小限制的。HTTP協議規範也沒有進行大小限制。
2）“POST資料量存在128K的大小限制”不夠準確，POST資料是沒有限制的，起限制作用的是伺服器的處理程式的處理能力。
3）對於ASP程式，Request物件處理每個表單域時存在100K的資料長度限制。但如果使用Request.BinaryRead則沒有這個限制。對於需要處理超過100K表單域資料的解決辦法，請參考後面的[參3]。
4）由這個延伸出去，對於IIS 6.0，微軟出於安全考慮，加大了限制[參4]。我們還需要注意：
IIS 6.0預設ASP POST資料量最大為200KB，每個表單域限制是100KB。
IIS 6.0預設上傳檔案的最大大小是4MB。
IIS 6.0預設最大請求頭是16KB。
IIS 6.0之前沒有這些限制。
建議：
1）弄清楚執行環境的預設設定值有助於你的設計及對出現的問題做快速的解決。
2）應該考慮伺服器版本。各個版本的IIS對這些引數的預設設定都不一樣，有必要的話，找資料整理出一份對照表。這樣開發與測試時都有個參考。
3）IIS 6.0的這些限制實際只是它的預設設定值而已，實際應用環境你可以修改它們。
在WINNT/system32/inetsrv/MetaBase.xml裡預設定義了：
AspBufferingLimit="4194304" 對應於上傳檔案最大大小
AspMaxRequestEntityAllowed="204800" 對應於POST最大資料量
...
結論(寫入Checklist)：
使用ASP時，需要考慮POST表單每個域一般讀取處理時有100KB的限制。充分考慮是否使用Request.Binary。
參考資料：
4、IIS 6.0 Troubleshooting [Client Requests Error-out or Time-out一節]