截至今日之前，我一直因為從某處看到get、post區別中寫的：get有長度限制，1024B。很抱歉在未經過個人的檢驗后，直接奉為正確的定義（也提醒我個人：以后概念理論，還是需要好好驗證或求證，要能在繁雜的網絡知識中，認真求真，以防以訛傳訛！！！）。
今日，看到前同事大牛多年前的csdn知識總結，發現原來一直信奉的1024Get請求長度，是錯誤的。下面把從權威官網的解釋復制過來，以做更正。
1、Http get方法提交的數據大小長度並沒有限制，Http協議規范沒有對URL長度進行限制。
目前說的get長度有限制，是特定的瀏覽器及服務器對它的限制。
各種瀏覽器和服務器的最大處理能力如下：
IE：對URL的最大限制為2083個字符，若超出這個數字，提交按鈕沒有任何反應。
Firefox：對Firefox瀏覽器URL的長度限制為：65536個字符。
Safari：URL最大長度限制為80000個字符。
Opera：URL最大長度限制為190000個字符。
Google(chrome)：URL最大長度限制為8182個字符。
Apache(Server)：能接受的最大url長度為8192個字符（這個准確度待定？？？）
Microsoft Internet Information Server(IIS)：n能接受最大url的長度為16384個字符。
2、理論上講，post是沒有大小限制的。Http協議規范也沒有進行大小限制，起限制作用的是服務器處理程序的處理能力。
Tomcat下默認post長度為2M，可通過修改conf/server.xml中的“maxPostSize=0”來取消對post大小的限制。
注意：（若長度超限，則服務端返回414標識）
1、首先即使有長度限制，也是限制的是整個URI長度，而不僅僅是你的參數值數據長度。
2、HTTP協議從未規定GET/POST的請求長度限制是多少
3、所謂的請求長度限制是由瀏覽器和web服務器決定和設置的，瀏覽器和web服務器的設定均不一樣，
這依賴於各個瀏覽器廠家的規定或者可以根據web服務器的處理能力來設定。
GET VS POST擴展：
1、多數瀏覽器對於POST采用兩階段發送數據的，先發送請求頭，再發送請求體，即使參數再少再短，也會被分成兩個步驟來發送（相對於GET）,也就是第一步發送header數據，第二部再發送body部分。Http是應用層的協議，而再傳輸層有些情況TCP會出現兩次連結的過程，http協議本身不保存狀態信息，一次請求一次響應。對於TCP而言，通信次數越多反而可靠性越低，能在一次連結中傳輸完需要的信息是最可靠的，所以盡量使用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（跨站請求偽造）。