1.??? Get方法長度限制
Http Get方法提交的數(shù)據(jù)大小長度并沒有限制，HTTP協(xié)議規(guī)范沒有對URL長度進(jìn)行限制。這個限制是特定的瀏覽器及服務(wù)器對它的限制。
如：IE對URL長度的限制是2083字節(jié)(2K+35)。
下面就是對各種瀏覽器和服務(wù)器的最大處理能力做一些說明.
Microsoft Internet Explorer (Browser)
IE瀏覽器對URL的最大限制為2083個字符，如果超過這個數(shù)字，提交按鈕沒有任何反應(yīng)。
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個字符。
通過上面的數(shù)據(jù)可知，為了讓所有的用戶都能正常瀏覽， URL最好不要超過IE的最大長度限制(2083個字符），當(dāng)然，如果URL不直接提供給用戶，而是提供給程序調(diào)用，這時的長度就只受Web服務(wù)器影響了。
注：對于中文的傳遞，最終會為urlencode后的編碼形式進(jìn)行傳遞，如果瀏覽器的編碼為UTF8的話，一個漢字最終編碼后的字符長度為9個字符。
因此如果使用的 GET 方法，最大長度等于URL最大長度減去實(shí)際路徑中的字符數(shù)。
理論上講，POST是沒有大小限制的。HTTP協(xié)議規(guī)范也沒有進(jìn)行大小限制，起限制作用的是服務(wù)器的處理程序的處理能力。
如：在Tomcat下取消POST大小的限制（Tomcat默認(rèn)2M）；
額。傳了個2.2m的圖片轉(zhuǎn)base64導(dǎo)出word帶圖片用直接post請求報錯。長點(diǎn)心。
打開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" (設(shè)為0是取消POST的大小限制)
剛看到群里又有同學(xué)在說 HTTP 協(xié)議下的?Get 請求參數(shù)長度是有大小限制的，最大不能超過
?XX，而 Post 是無限制的，看到這里，我想他們定是看多了一些以訛傳訛的博客或者書籍，
導(dǎo)致一種理解上的誤區(qū)：
1、首先即使有長度限制，也是限制的是整個 URI 長度，而不僅僅是你的參數(shù)值數(shù)據(jù)長度。
2、HTTP 協(xié)議從未規(guī)定 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 服務(wù)器決定和設(shè)置的，各種瀏覽器和 web 服務(wù)器的設(shè)定
均不一樣，這依賴于各個瀏覽器廠家的規(guī)定或者可以根據(jù) web 服務(wù)器的處理能力來設(shè)定。
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、多數(shù)瀏覽器對于POST采用兩階段發(fā)送數(shù)據(jù)的，先發(fā)送請求頭，再發(fā)送請求體，即使參數(shù)再少再短，也會被分成兩個步驟來發(fā)送（相對于GET），也就是第一步發(fā)送header數(shù)據(jù)，第二步再發(fā)送body部分。HTTP是應(yīng)用層的協(xié)議，而在傳輸層有些情況TCP會出現(xiàn)兩次連結(jié)的過程，HTTP協(xié)議本身不保存狀態(tài)信息，一次請求一次響應(yīng)。對于TCP而言，通信次數(shù)越多反而靠性越低，能在一次連結(jié)中傳輸完需要的消息是最可靠的，盡量使用GET請求來減少網(wǎng)絡(luò)耗時。如果通信時間增加，這段時間客戶端與服務(wù)器端一直保持連接狀態(tài)，在服務(wù)器側(cè)負(fù)載可能會增加，可靠性會下降。
Tips：關(guān)于這點(diǎn)你可以參考：Yahoo網(wǎng)站性能優(yōu)化指南之服務(wù)器篇
http://segmentfault.com/a/1190000000353790
http://developer.yahoo.com/performance/rules.html
http://blogread.cn/it/article/6100?f=wbYSLOW法則中，為什么yahoo推薦用GET代替POST？
上面這篇文章介紹了?wireshark?抓包驗(yàn)證 post 兩次發(fā)包，get 一次發(fā)包的全過程，推薦閱讀。
2、GET請求能夠被cache，GET請求能夠被保存在瀏覽器的瀏覽歷史里面（密碼等重要數(shù)據(jù)GET提交，別人查看歷史記錄，就可以直接看到這些私密數(shù)據(jù)）POST不進(jìn)行緩存。
3、GET參數(shù)是帶在URL后面，傳統(tǒng)IE中URL的最大可用長度為2048字符，其他瀏覽器對URL長度限制實(shí)現(xiàn)上有所不同。POST請求無長度限制（目前理論上是這樣的）。
4、GET提交的數(shù)據(jù)大小，不同瀏覽器的限制不同，一般在2k-8K之間，POST提交數(shù)據(jù)比較大，大小靠服務(wù)器的設(shè)定值限制，而且某些數(shù)據(jù)只能用 POST 方法「攜帶」，比如 file。
5、全部用POST不是十分合理，最好先把請求按功能和場景分下類，對數(shù)據(jù)請求頻繁，數(shù)據(jù)不敏感且數(shù)據(jù)量在普通瀏覽器最小限定的2k范圍內(nèi)，這樣的情況使用GET。其他地方使用POST。
6、GET 的本質(zhì)是「得」，而 POST 的本質(zhì)是「給」。而且，GET 是「冪等」的，在這一點(diǎn)上，GET 被認(rèn)為是「安全的」。但實(shí)際上 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).
設(shè)置為0和負(fù)數(shù)均可以代表不限制
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).
不可以設(shè)置為0，只能是負(fù)數(shù)代表不限制
還有必須要?multipart/form-data才能起效。
四種常見的 POST 提交數(shù)據(jù)方式對應(yīng)的content-type取值
application/x-www-form-urlencoded
這應(yīng)該是最常見的 POST 提交數(shù)據(jù)的方式了。瀏覽器的原生 form 表單，如果不設(shè)置 enctype 屬性，那么最終就會以 application/x-www-form-urlencoded 方式提交數(shù)據(jù)。請求類似于下面這樣（無關(guān)的請求頭在本文中都省略掉了）：
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；其次，提交的數(shù)據(jù)按照 key1=val1&key2=val2 的方式進(jìn)行編碼，key 和 val 都進(jìn)行了 URL 轉(zhuǎn)碼。大部分服務(wù)端語言都對這種方式有很好的支持。
很多時候，我們用 Ajax 提交數(shù)據(jù)時，也是使用這種方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認(rèn)值都是「application/x-www-form-urlencoded;charset=utf-8」。
multipart/form-data
這又是一個常見的 POST 數(shù)據(jù)提交的方式。我們使用表單上傳文件時，必須讓 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--
這個例子稍微復(fù)雜點(diǎn)。首先生成了一個 boundary 用于分割不同的字段，為了避免與正文內(nèi)容重復(fù)，boundary 很長很復(fù)雜。然后 Content-Type 里指明了數(shù)據(jù)是以 mutipart/form-data 來編碼，本次請求的 boundary 是什么內(nèi)容。消息主體里按照字段個數(shù)又分為多個結(jié)構(gòu)類似的部分，每部分都是以 --boundary 開始，緊接著內(nèi)容描述信息，然后是回車，最后是字段具體內(nèi)容（文本或二進(jìn)制）。如果傳輸?shù)氖俏募?，還要包含文件名和文件類型信息。消息主體最后以 --boundary-- 標(biāo)示結(jié)束。關(guān)于 mutipart/form-data 的詳細(xì)定義，請前往 rfc1867 查看。
這種方式一般用來上傳文件，各大服務(wù)端語言對它也有著良好的支持。
上面提到的這兩種 POST 數(shù)據(jù)的方式，都是瀏覽器原生支持的，而且現(xiàn)階段原生 form 表單也只支持這兩種方式。但是隨著越來越多的 Web 站點(diǎn)，尤其是 WebApp，全部使用 Ajax 進(jìn)行數(shù)據(jù)交互之后，我們完全可以定義新的數(shù)據(jù)提交方式，給開發(fā)帶來更多便利。
application/json
application/json 這個 Content-Type 作為響應(yīng)頭大家肯定不陌生。實(shí)際上，現(xiàn)在越來越多的人把它作為請求頭，用來告訴服務(wù)端消息主體是序列化后的 JSON 字符串。由于 JSON 規(guī)范的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務(wù)端語言也都有處理 JSON 的函數(shù)，使用 JSON 不會遇上什么麻煩。
JSON 格式支持比鍵值對復(fù)雜得多的結(jié)構(gòu)化數(shù)據(jù)，這一點(diǎn)也很有用。記得我?guī)啄昵白鲆粋€項(xiàng)目時，需要提交的數(shù)據(jù)層次非常深，我就是把數(shù)據(jù) JSON 序列化之后來提交的。不過當(dāng)時我是把 JSON 字符串作為 val，仍然放在鍵值對里，以 x-www-form-urlencoded 方式提交。
Google 的 AngularJS 中的 Ajax 功能，默認(rèn)就是提交 JSON 字符串。例如下面這段代碼：
var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
...
});
最終發(fā)送的請求是：
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
這種方案，可以方便的提交復(fù)雜的結(jié)構(gòu)化數(shù)據(jù)，特別適合 RESTful 的接口。各大抓包工具如 Chrome 自帶的開發(fā)者工具、Firebug、Fiddler，都會以樹形結(jié)構(gòu)展示 JSON 數(shù)據(jù)，非常友好。但也有些服務(wù)端語言還沒有支持這種方式，例如 php 就無法通過 $_POST 對象從上面的請求中獲得內(nèi)容。這時候，需要自己動手處理下：在請求頭中 Content-Type 為 application/json 時，從 php://input 里獲得原始輸入流，再 json_decode 成對象。一些 php 框架已經(jīng)開始這么做了。
當(dāng)然 AngularJS 也可以配置為使用 x-www-form-urlencoded 方式提交數(shù)據(jù)。如有需要，可以參考這篇文章。
text/xml
我的博客之前提到過 XML-RPC（XML Remote Procedure Call）。它是一種使用 HTTP 作為傳輸協(xié)議，XML 作為編碼方式的遠(yuǎn)程調(diào)用規(guī)范。典型的 XML-RPC 請求是這樣的：
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
examples.getStateName
41
XML-RPC 協(xié)議簡單、功能夠用，各種語言的實(shí)現(xiàn)都有。它的使用也很廣泛，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服務(wù)等等。JavaScript 中，也有現(xiàn)成的庫支持以這種方式進(jìn)行數(shù)據(jù)交互，能很好的支持已有的 XML-RPC 服務(wù)。不過，我個人覺得 XML 結(jié)構(gòu)還是過于臃腫，一般場景用 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協(xié)議詳解
post方式相比get安全,攜帶數(shù)據(jù)更大，我準(zhǔn)備所有數(shù)據(jù)都用post方式獲取，這樣好嗎？
http://segmentfault.com/q/1010000000213082
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html淺談CSRF攻擊方式
