轉自：http://my.oschina.net/leejun2005/blog/136820
剛看到羣裏又有同學在說 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
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（跨站請求僞造）。