1. Get方法長度限制
Http Get方法提交的數據大小長度並沒有限制，HTTP協議規范沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。
如：IE對URL長度的限制是2083字節(2K+35)。
下面就是對各種瀏覽器和服務器的最大處理能力做一些說明.
Microsoft Internet Explorer (Browser)
IE瀏覽器對URL的最大限制為2083個字符，如果超過這個數字，提交按鈕沒有任何反應。
Firefox (Browser)
對於Firefox瀏覽器URL的長度限制為65,536個字符。
Safari (Browser)
URL最大長度限制為 80,000個字符。
Opera (Browser)
URL最大長度限制為190,000個字符。
Google (chrome)
URL最大長度限制為8182個字符。
Apache (Server)
能接受最大url長度為8,192個字符。
Microsoft Internet Information Server(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 <="" p="" style="word-wrap: break-word;">
debug="0"
acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true"
port="8080"
redirectPort="8443"
enableLookups="false"
minSpareThreads="25"
maxSpareThreads="75"
maxThreads="150"
maxPostSize="0"
URIEncoding="GBK">
增加紅色字體部分 maxPostSize="0" (設為0是取消POST的大小限制)
有人說 HTTP 協議下的 Get 請求參數長度是有大小限制的，最大不能超過XX，而 Post 是無限制的，看到這里，我想他們定是看多了一些以訛傳訛的博客或者書籍，導致一種理解上的誤區：
1、首先即使有長度限制，也是限制的是整個 URI 長度，而不僅僅是你的參數值數據長度。
2、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.
3、所謂的請求長度限制是由瀏覽器和 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：
1、多數瀏覽器對於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 一次發包的全過程，推薦閱讀。
2、GET請求能夠被cache，GET請求能夠被保存在瀏覽器的瀏覽歷史里面（密碼等重要數據GET提交，別人查看歷史記錄，就可以直接看到這些私密數據）POST不進行緩存。
3、GET參數是帶在URL后面，傳統IE中URL的最大可用長度為2048字符，其他瀏覽器對URL長度限制實現上有所不同。POST請求無長度限制（目前理論上是這樣的）。
4、GET提交的數據大小，不同瀏覽器的限制不同，一般在2k-8K之間，POST提交數據比較大，大小靠服務器的設定值限制，而且某些數據只能用 POST 方法「攜帶」，比如 file。
5、全部用POST不是十分合理，最好先把請求按功能和場景分下類，對數據請求頻繁，數據不敏感且數據量在普通瀏覽器最小限定的2k范圍內，這樣的情況使用GET。其他地方使用POST。
6、GET 的本質是「得」，而 POST 的本質是「給」。而且，GET 是「冪等」的，在這一點上，GET 被認為是「安全的」。但實際上 server 端也可以用作資源更新，但是這種用法違反了約定，容易造成 CSRF（跨站請求偽造）。
REF：
http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request 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協議詳解
http://segmentfault.com/q/1010000000213082 post方式相比get安全,攜帶數據更大，我准備所有數據都用post方式獲取，這樣好嗎？
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html 淺談CSRF攻擊方式