http get 方式引數的長度限制
這個問題一直以來似乎是被N多人誤解,其實Http Get方法提交的資料大小長度並沒有限制,而是IE瀏覽器本身對位址列URL長度有最大長度限制:2048個字元。
當您從 WinInet 應用程式到 Web 伺服器傳送一個長的查詢字串時,查詢字串可能會被截斷。
出現此問題是由於中 WinInet,定義 Wininet.h 檔案中,如下所示的 URL 的長度限制:
[cpp] view plaincopyprint?- #define INTERNET_MAX_PATH_LENGTH 2048
-
#define INTERNET_MAX_SCHEME_LENGTH 32 // longest protocol name length
- #define INTERNET_MAX_URL_LENGTH (INTERNET_MAX_SCHEME_LENGTH + sizeof("://") + INTERNET_MAX_PATH_LENGTH)
此行為是設計使然。
注意: 因為 Internet Explorer 和 Internet 傳輸的控制也使用 WinInet,可能會出現相同的問題。
若要解決此問題,使用 HTTP POST 方法。
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs. ‘>以下附上微軟官方的一段說明:
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs. ‘>Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.
If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.
However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL. ‘>However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.
RFC 2616, “Hypertext Transfer Protocol — HTTP/1.1,” does not specify any requirement for URL length.
其他文章內容摘要:
最近一直在做Web相關的專案,熟悉Web開發的人都知道,我們經常需要通過URL來傳遞引數,即所謂的“GET”方法,還有一種是“POST”,兩種方法都用的很多。其中,GET方法適合引數資料量比較小的情況,GET方法比較直觀,通過URL就能大概知道回傳了哪些引數。POST適合向伺服器回傳大量的資料,沒有GET方法直觀。以前我大概看過,通過URL回傳引數有個長度限制,當時我看的是1024位元組,由於以前做的專案,引數較少,基本不可能超過1024,所以我也沒有仔細研究過到底是不是1024位元組。最近這個專案,由於引數較多,已經超過1024了,顯然我要考慮URL能夠接收的最大長度了,在網上搜了一下,得到了準確答案:HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制。IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決於作業系統的支援。[參考http://support.microsoft.com/kb/q208427/]。我這就放心,2083位元組應該是夠用了,呵呵。至於POST方法,可以參考如下這篇文章的介紹。
表單Post&Get兩個長度限制問題的分析
一、問題起因 在某專案釋放後Bug統計的附件《釋放後問題》裡有:問題 | 原因 | 分析 | 備註 |
CSV處理時,如果處理的主題數過多,發生URL引數上限的錯誤; | 可變長度的引數通過URL方式傳遞,會造成這種潛在的錯誤發生。 | 1、屬於2次發生問題,開發方面沒有及時通過checklist等方式向組員傳達相關注意事項; 2、測試時沒有作大批量資料的測試; |
1、作為經驗新增至CheckList中,加強組內共享、檢查的效果; 2、加強測試點是否完備的檢查,重點關注對開發方面共性問題的測試; |
通過對模組原有GUI狀況確認,進行CSV輸出時,輸出結果很大的場合,CSV檔案的內容不能輸出。 | 沒有考慮到POST資料量存在128K的大小限制。 | 這屬於新問題,以前從未遇見過,也沒有進行過大規模的資料量測試 | 已將此類檢查列出CheckList中 |
AspBufferingLimit="4194304" 對應於上傳檔案最大大小
AspMaxRequestEntityAllowed="204800" 對應於POST最大資料量 ... 結論(寫入Checklist): 使用ASP時,需要考慮POST表單每個域一般讀取處理時有100KB的限制。充分考慮是否使用Request.Binary。