1.請求長度
RFC對於Get和Post請求並沒有長度的限制。
但是浏覽器有限制，比如IE浏覽器Get請求不能超過2083個字符，而火狐浏覽器不能超過65536個字符。浏覽器對於Post請求則沒有限制。
服務器對Get和Post請求可以進行限制，以Tomcat為例，Connector中的maxHttpHeaderSize限制了Get請求的長度，而maxPostSize則可以限制Post請求的長度。由此可見兩種請求的區別，get請求在Http Header部分，而Post請求在Http Body部分。
2.編碼
Spring的CharacterEncodingFilter和request的setCharacterEncoding僅僅針對Http Body,這兩種方式對於Get請求不起作用。
以Tomcat為例，可以調整URIEncoding參數或者啟用useBodyEncodingForURI來調整Get請求的編碼。URIEncoding默認是ISO-8859-1編碼。
當然，這種方式不具通用性，需要修改中間件的配置。
還有一種方法，在前台頁面通過JS對中文進行兩次編碼。
以如下前台頁面為例，將兩次編碼的中文數據提交到後台Servlet。
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script language='javascript'>
function get(){
var data='中文請求';
data=encodeURIComponent(encodeURIComponent(data));
document.getElementById("a").href="http://127.0.0.1:8080/Web/Encoding?name="+data;
}
</script>
</head>
<body>
<a onClick="get()" id="a">Click<a/>
</body>
</html>
Servlet解碼一次，即可得到中文數據。
String name = URLDecoder.decode(request.getParameter("name"),"utf-8");
以"中文請求"為例
前台JS第一次編碼的結果：%E4%B8%AD%E6%96%87%E8%AF%B7%E6%B1%82
前台JS第二次編碼的結果：%25E4%25B8%25AD%25E6%2596%2587%25E8%25AF%25B7%25E6%25B1%2582
在第一次編碼之後，數據已經都是ASCII字符，所以二次編碼就是將第一次編碼中的"%"進一步編碼為"%25"
請求到達Tomcat之後，Tomcat會根據URIEncoding自動解碼(默認為ISO-8859-1),所以在進入Servlet的doGet方法之前，數據已經還原為
“%E4%B8%AD%E6%96%87%E8%AF%B7%E6%B1%82”
故最後使用String name = URLDecoder.decode(request.getParameter("name"),"utf-8");就可以得出正確的數據。
這種方式的好處是不用修改中間件的配置。缺點是兩次編碼會導致URL膨脹。
3.緩存內容
浏覽器會緩存get請求的結果直至過期，這也是JSONP技術需要使用隨機數的原因。
