關於 HTTP GET/POST 請求參數長度最大值的一個理解誤區（轉載）

1. Get方法長度限制

Http Get方法提交的數據大小長度並無限制，HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。下面就是對各類瀏覽器和服務器的最大處理能力作一些說明.

瀏覽器/服務器	說明
Microsoft Internet Explorer	IE瀏覽器對URL的最大限制爲2083個字符，若是超過這個數字，提交按鈕沒有任何反應。
Firefox	對於Firefox瀏覽器URL的長度限制爲65,536個字符
Safari	URL最大長度限制爲 80,000個字符
Opera	URL最大長度限制爲190,000個字符
Google chrome	URL最大長度限制爲8182個字符
Apache Server	能接受最大url長度爲8,192個字符
IIS	能接受最大url的長度爲16,384個字符

 

經過上面的數據可知，爲了讓全部的用戶都能正常瀏覽， URL最好不要超過IE的最大長度限制(2083個字符），固然，若是URL不直接提供給用戶，而是提供給程序調用，這時的長度就只受Web服務器影響了。
注：對於中文的傳遞，最終會爲urlencode後的編碼形式進行傳遞，若是瀏覽器的編碼爲UTF8的話，一個漢字最終編碼後的字符長度爲9個字符。

所以若是使用的 GET 方法，最大長度等於URL最大長度減去實際路徑中的字符數。

2.POST方法長度限制

理論上講，POST是沒有大小限制的。HTTP協議規範也沒有進行大小限制，起限制做用的是服務器的處理程序的處理能力。

如：在Tomcat下取消POST大小的限制（Tomcat默認2M）；

打開tomcat目錄下的conf目錄，打開server.xml 文件，修改 

<Connector
debug="0"
acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true"
port="8080"
redirectPort="8443"
enableLookups="false"
minSpareThreads="25"
maxSpareThreads="75"
maxThreads="150"
maxPostSize="0"
URIEncoding="GBK"
> 
</Connector>

增長紅色字體部分 maxPostSize="0" (設爲0是取消POST的大小限制)

 

剛看到羣裏又有同窗在說 HTTP 協議下的 Get 請求參數長度是有大小限制的，最大不能超過XX，而 Post 是無限制的，看到這裏，我想他們定是看多了一些以訛傳訛的博客或者書籍，致使一種理解上的誤區：

一、首先即便有長度限制，也是限制的是整個 URI 長度，而不只僅是你的參數值數據長度。

二、HTTP 協議從未規定 GET/POST 的請求長度限制是多少。

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). 

 Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

三、所謂的請求長度限制是由瀏覽器和 web 服務器決定和設置的，各類瀏覽器和 web 服務器的設定均不同，這依賴於各個瀏覽器廠家的規定或者能夠根據 web 服務器的處理能力來設定。

The limit is in MSIE and Safari about 2KB, in Opera about 4KB and in Firefox about 8KB, (255 bytes if we count very old browsers) . We may thus assume that 8KB is the maximum possible length and that 2KB is a more affordable length to rely on at the server side and that 255 bytes is the safest length to assume that the entire URL will come in.

If the limit is exceeded in either the browser or the server, most will just truncate the characters outside the limit without any warning. Some servers however may send a HTTP 414 error. If you need to send large data, then better use POST instead of GET. Its limit is much higher, but more dependent on the server used than the client. Usually up to around 2GB is allowed by the average webserver. This is also configureable somewhere in the server settings. The average server will display a server-specific error/exception when the POST limit is exceeded, usually as HTTP 500 error.

HTTP 1.1 defines Status Code 414 Request-URI Too Long for the cases where a server-defined limit is reached. You can see further details on RFC 2616. For the case of client-defined limits, there is no sense on the server returning something, because the server won't receive the request at all.

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.

 

附 GET VS POST：

一、多數瀏覽器對於POST採用兩階段發送數據的，先發送請求頭，再發送請求體，即便參數再少再短，也會被分紅兩個步驟來發送（相對於GET），也就是第一步發送header數據，第二步再發送body部分。HTTP是應用層的協議，而在傳輸層有些狀況TCP會出現兩次連結的過程，HTTP協議自己不保存狀態信息，一次請求一次響應。對於TCP而言，通訊次數越多反而靠性越低，能在一次連結中傳輸完須要的消息是最可靠的，儘可能使用GET請求來減小網絡耗時。若是通訊時間增長，這段時間客戶端與服務器端一直保持鏈接狀態，在服務器側負載可能會增長，可靠性會降低。

Tips：關於這點你能夠參考：Yahoo網站性能優化指南之服務器篇

http://segmentfault.com/a/1190000000353790

http://developer.yahoo.com/performance/rules.html

http://blogread.cn/it/article/6100?f=wb    YSLOW法則中，爲何yahoo推薦用GET代替POST？

上面這篇文章介紹了 wireshark 抓包驗證 post 兩次發包，get 一次發包的全過程，推薦閱讀。

二、GET請求可以被cache，GET請求可以被保存在瀏覽器的瀏覽歷史裏面（密碼等重要數據GET提交，別人查看歷史記錄，就能夠直接看到這些私密數據）POST不進行緩存。

三、GET參數是帶在URL後面，傳統IE中URL的最大可用長度爲2048字符，其餘瀏覽器對URL長度限制實現上有所不一樣。POST請求無長度限制（目前理論上是這樣的）。

四、GET提交的數據大小，不一樣瀏覽器的限制不一樣，通常在2k-8K之間，POST提交數據比較大，大小靠服務器的設定值限制，並且某些數據只能用 POST 方法「攜帶」，好比 file。

五、所有用POST不是十分合理，最好先把請求按功能和場景分下類，對數據請求頻繁，數據不敏感且數據量在普通瀏覽器最小限定的2k範圍內，這樣的狀況使用GET。其餘地方使用POST。

六、GET 的本質是「得」，而 POST 的本質是「給」。並且，GET 是「冪等」的，在這一點上，GET 被認爲是「安全的」。但實際上 server 端也能夠用做資源更新，可是這種用法違反了約定，容易形成 CSRF（跨站請求僞造）。

REF：

maximum length of HTTP GET request?

http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request  

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15 Request-URI Too Long

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 General Syntax

http://www.cnblogs.com/xiaotaomaomao/articles/986070.html

http://www.cnblogs.com/TankXiao/archive/2012/02/13/2342672.html HTTP協議詳解

post方式相比get安全,攜帶數據更大，我準備全部數據都用post方式獲取，這樣好嗎？

http://segmentfault.com/q/1010000000213082  

http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html   淺談CSRF攻擊方式