1、問題原由
在某項目釋放後Bug統計的附件《釋放後問題》裏有:
問題 緣由 分析 備註
CSV處理時,若是處理的主題數過多,發生URL參數上限的錯誤; 可變長度的參數經過URL方式傳遞,會形成這種潛在的錯誤發生。 一、屬於2次發生問題,開發方面沒有及時經過checklist等方式向組員傳達相關注意事項;
二、測試時沒有做大批量數據的測試; 一、做爲經驗添加至CheckList中,增強組內共享、檢查的效果;
二、增強測試點是否完備的檢查,重點關注對開發方面共性問題的測試;
經過對模塊原有GUI情況確認,進行CSV輸出時,輸出結果很大的場合,CSV文件的內容不能輸出。 沒有考慮到POST數據量存在128K的大小限制。 這屬於新問題,之前從未碰見過,也沒有進行過大規模的數據量測試 已將此類檢查列出CheckList中 瀏覽器
作爲一種經驗積累,這些問題、緣由及解決辦法將被列入Checklist,那麼:
第一個問題:URL參數上限的提法準確嗎?上限是多少?
第二個問題:爲何POST時數據有限制?限制是128K嗎?
2、問題分析
一、第一個:
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字節的限制。
二、第二個:
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安全
--------------------- 本文來自 gaozhigang 的CSDN 博客 ,全文地址請點擊:https://blog.csdn.net/gaozhigang/article/details/4445458?utm_source=copy服務器