從進入IT這個行業，我接觸到的就是get有長度限制，1024B。時至今日，好尷尬！
Http的get請求方法提交的數據大小長度並沒有限制，Http協議規範沒有對URL長度進行限制。目前說的get長度有限制，是特定的瀏覽器及服務器對它的限制。
各種瀏覽器和服務器的最大處理能力如下：
IE：對URL的最大限制爲2083個字符，若超出這個數字，提交按鈕沒有任何反應。
Firefox：對Firefox瀏覽器URL的長度限制爲：65536個字符。
Safari：URL最大長度限制爲80000個字符。
Opera：URL最大長度限制爲190000個字符。
Chrome：URL最大長度限制爲8182個字符。
Apache(Server)：能接受的最大url長度爲8192個字符（這個準確度待定？？？） Microsoft Internet Information Server(IIS)：n能接受最大url的長度爲16384個字符。理論上講，post是沒有大小限制的。Http協議規範也沒有進行大小限制，起限制作用的是服務器處理程序的處理能力。
Tomcat下默認post長度爲2M，可通過修改conf/server.xml中的“maxPostSize=0”來取消對post大小的限制。
注意：（若長度超限，則服務端返回414標識）
- 首先即使有長度限制，也是限制的是整個URI長度，而不僅僅是你的參數值數據長度。
- HTTP協議從未規定GET/POST的請求長度限制是多少
- 所謂的請求長度限制是由瀏覽器和web服務器決定和設置的，瀏覽器和web服務器的設定均不一樣，這依賴於各個瀏覽器廠家的規定或者可以根據web服務器的處理能力來設定。
GET VS POST擴展：
- 多數瀏覽器對於POST採用兩階段發送數據的，先發送請求頭，再發送請求體，即使參數再少再短，也會被分成兩個步驟來發送（相對於GET）,也就是第一步發送header數據，第二部再發送body部分。Http是應用層的協議，而再傳輸層有些情況TCP會出現兩次連結的過程，http協議本身不保存狀態信息，一次請求一次響應。對於TCP而言，通信次數越多反而可靠性越低，能在一次連結中傳輸完需要的信息是最可靠的，所以儘量使用GET請求來減少網絡耗時。如果通信時間增加，這段時間客戶端於服務器端一直保持連接狀態，在服務器側負載可能會增加，可靠性會下降。
- GET請求能夠被cache，GET請求能夠被保存在瀏覽器的瀏覽歷史裏面（密碼等重要數據GET提交，別人查看歷史記錄，就可以直接看到這些私密數據）POST不進行緩存。
- GET參數是帶在URL後面，傳統IE中URL的最大可用長度爲2048字符，其他瀏覽器對URL長度限制實現上有所不同。POST請求無長度限制（目前理論上是這樣）。 4. GET提交的數據大小，不同瀏覽器的限制不同，一般在2k-8k之間，POST提交數據比較大，大小靠服務器的設定值限制，而且某些數據只能用POST方法【攜帶】，比如file。
- 全部用POST不是十分合理，最好先把請求按功能和場景分下類，對數據請求頻繁，數據不敏感且數據量在普通瀏覽器最小限定的2k範圍內，這種情況使用GET。其他地方使用POST。
- GET的本質是【得】，而POST的本質是【給】。而且，GET是【冪等】的，在這一點上，GET被認爲是【安全的】。實際上server端也可以用作資源更新，但是這種用法違反了約定，容易造成CSRF（跨站請求僞造）。