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最大長度減去實際路徑中的字符數。
理論上講，POST是沒有大小限制的。HTTP協議規范也沒有進行大小限制，起限制作用的是服務器的處理程序的處理能力。
如：在Tomcat下取消POST大小的限制（Tomcat默認2M）；
額。傳了個2.2m的圖片轉base64導出word帶圖片用直接post請求報錯。長點心。
打開tomcat目錄下的conf目錄，打開server.xml 文件，修改
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=wbYSLOW法則中，為什么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（跨站請求偽造）。
tomcat7.0.63之前：
maxPostSizeThe maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value?less than or equal to 0. If not specified, this attribute is set to 2097152 (2 megabytes).
設置為0和負數均可以代表不限制
tomcat7.0.63（包含）之后：
maxPostSizeThe maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value?less than zero. If not specified, this attribute is set to 2097152 (2 megabytes).
不可以設置為0，只能是負數代表不限制
還有必須要?multipart/form-data才能起效。
四種常見的 POST 提交數據方式對應的content-type取值
application/x-www-form-urlencoded
這應該是最常見的 POST 提交數據的方式了。瀏覽器的原生 form 表單，如果不設置 enctype 屬性，那么最終就會以 application/x-www-form-urlencoded 方式提交數據。請求類似于下面這樣（無關的請求頭在本文中都省略掉了）：
POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3
首先，Content-Type 被指定為 application/x-www-form-urlencoded；其次，提交的數據按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行了 URL 轉碼。大部分服務端語言都對這種方式有很好的支持。
很多時候，我們用 Ajax 提交數據時，也是使用這種方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認值都是「application/x-www-form-urlencoded;charset=utf-8」。
multipart/form-data
這又是一個常見的 POST 數據提交的方式。我們使用表單上傳文件時，必須讓 form 的 enctyped 等于這個值。直接來看一個請求示例：
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
這個例子稍微復雜點。首先生成了一個 boundary 用于分割不同的字段，為了避免與正文內容重復，boundary 很長很復雜。然后 Content-Type 里指明了數據是以 mutipart/form-data 來編碼，本次請求的 boundary 是什么內容。消息主體里按照字段個數又分為多個結構類似的部分，每部分都是以 --boundary 開始，緊接著內容描述信息，然后是回車，最后是字段具體內容（文本或二進制）。如果傳輸的是文件，還要包含文件名和文件類型信息。消息主體最后以 --boundary-- 標示結束。關于 mutipart/form-data 的詳細定義，請前往 rfc1867 查看。
這種方式一般用來上傳文件，各大服務端語言對它也有著良好的支持。
上面提到的這兩種 POST 數據的方式，都是瀏覽器原生支持的，而且現階段原生 form 表單也只支持這兩種方式。但是隨著越來越多的 Web 站點，尤其是 WebApp，全部使用 Ajax 進行數據交互之后，我們完全可以定義新的數據提交方式，給開發帶來更多便利。
application/json
application/json 這個 Content-Type 作為響應頭大家肯定不陌生。實際上，現在越來越多的人把它作為請求頭，用來告訴服務端消息主體是序列化后的 JSON 字符串。由于 JSON 規范的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務端語言也都有處理 JSON 的函數，使用 JSON 不會遇上什么麻煩。
JSON 格式支持比鍵值對復雜得多的結構化數據，這一點也很有用。記得我幾年前做一個項目時，需要提交的數據層次非常深，我就是把數據 JSON 序列化之后來提交的。不過當時我是把 JSON 字符串作為 val，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交。
Google 的 AngularJS 中的 Ajax 功能，默認就是提交 JSON 字符串。例如下面這段代碼：
var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
...
});
最終發送的請求是：
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
這種方案，可以方便的提交復雜的結構化數據，特別適合 RESTful 的接口。各大抓包工具如 Chrome 自帶的開發者工具、Firebug、Fiddler，都會以樹形結構展示 JSON 數據，非常友好。但也有些服務端語言還沒有支持這種方式，例如 php 就無法通過 $_POST 對象從上面的請求中獲得內容。這時候，需要自己動手處理下：在請求頭中 Content-Type 為 application/json 時，從 php://input 里獲得原始輸入流，再 json_decode 成對象。一些 php 框架已經開始這么做了。
當然 AngularJS 也可以配置為使用 x-www-form-urlencoded 方式提交數據。如有需要，可以參考這篇文章。
text/xml
我的博客之前提到過 XML-RPC（XML Remote Procedure Call）。它是一種使用 HTTP 作為傳輸協議，XML 作為編碼方式的遠程調用規范。典型的 XML-RPC 請求是這樣的：
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
examples.getStateName
41
XML-RPC 協議簡單、功能夠用，各種語言的實現都有。它的使用也很廣泛，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服務等等。JavaScript 中，也有現成的庫支持以這種方式進行數據交互，能很好的支持已有的 XML-RPC 服務。不過，我個人覺得 XML 結構還是過于臃腫，一般場景用 JSON 會更靈活方便。
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.15Request-URI Too Long
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1General Syntax
http://www.cnblogs.com/xiaotaomaomao/articles/986070.html
http://www.cnblogs.com/TankXiao/archive/2012/02/13/2342672.htmlHTTP協議詳解
post方式相比get安全,攜帶數據更大，我準備所有數據都用post方式獲取，這樣好嗎？
http://segmentfault.com/q/1010000000213082
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html淺談CSRF攻擊方式
