摘要：通常情況下，由瀏覽器向服務器發(fā)起請求，服務器向瀏覽器返回響應。響應包含了請求的狀態(tài)信息以及可能被請求的內容。但是這個限制是針對所有請求的，與沒有關系。根據(jù)規(guī)范，表示可能修改變服務器上的資源的請求。

本文主要對GET與POST基本區(qū)別進行匯總并掌握，如有錯誤與遺漏之處，請指出。

HTTP（即超文本傳輸協(xié)議）是現(xiàn)代網(wǎng)絡中最常見和常用的協(xié)議之一，
設計它的目的是保證客戶機和服務器之間的通信。
HTTP 的工作方式是客戶端與服務器之間的  “請求-響應”   協(xié)議。
客戶端可以是 Web 瀏覽器，服務器端可以是計算機上的某些網(wǎng)絡應用程序。
通常情況下，由瀏覽器向服務器發(fā)起 HTTP 請求，服務器向瀏覽器返回響應。
響應包含了請求的狀態(tài)信息以及可能被請求的內容。

HTTP方法有OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT

其中兩種常見的 HTTP 請求就是：GET 和 POST。
區(qū)別： _GET_是從服務器上獲取數(shù)據(jù)，_POST_則是向指定的資源提交要被處理的數(shù)據(jù)

請求報文的格式:
　　< request line >
　　< headers >
　　< blank line >
　　< request-body >

GET請求數(shù)據(jù)按照查詢字符串（名稱/值對）方式，放置在HTTP請求協(xié)議頭（headers）中，也就是URL之后；

而POST提交的數(shù)據(jù)則放在實體的主體（request-body）中。

　　_4.1 緩存：_ GET會被緩存，POST不能。

　　_4.2 書簽：_ GET可收藏為書簽，POST不可收藏為書簽

　　_4.3 歷史記錄：_ GET請求的URL，參數(shù)會被瀏覽器保留在歷史中,POST參數(shù)不會。

　　_4.4 默認請求：_ 在from提交的時候，如果不指定Method，則默認為get請求。

GET請求是可以被客戶端緩存的。會比POST高效。

AJAX環(huán)境中GET響應快速，POST需要先發(fā)送HTTP頭部(headers) 再發(fā)送報文實體的主體(request-body)中的數(shù)據(jù)。

6.1 GET限制數(shù)據(jù)集的值必須為ASCII字符；

GET提交的數(shù)據(jù)將會附加在url之后，以?分開與url分開。

1.以 ？ 來分隔URL和數(shù)據(jù);
2.以& 來分隔參數(shù);
3.如果數(shù)據(jù)是英文或數(shù)字，原樣發(fā)送;
4.如果數(shù)據(jù)是中文或其它字符，則進行BASE64編碼
5.GET將數(shù)據(jù)的按照variable=value的形式，添加到URL后面;
如:http:// www.abc.com/?username=yt&id=123

6.2 POST沒有限制，允許二進制數(shù)據(jù)。

POST是將數(shù)據(jù)放在請求的數(shù)據(jù)體（request-body）中，按照查詢字符串（名稱/值對）相對應的方式，傳遞到所指向URL；

7.1.GET方式提交的數(shù)據(jù)最多只能是1024字節(jié)，POST支持較大數(shù)據(jù)傳輸

7.2HTTP協(xié)議對GET和POST都沒有對長度的限制

RFC 2616 中明確對 uri 的長度并沒有限制。
不過雖然在RFC中并沒有對uri的長度進行限制，但是各大瀏覽器廠家實現(xiàn)上限制了URL的長度。

 IE對URL長度的限制是2083字節(jié)(2K+35)

而對于URL長度上的限制，有兩方面的原因造成 ( 安全考慮 )：

 瀏覽器：據(jù)說早期的瀏覽器會對URL長度做限制。IE對URL長度會限制在2083個字符內，Chrome會崩潰。
 服務器：URL長了，對服務器處理也是一種負擔。
 原本一個會話就沒有多少數(shù)據(jù)，現(xiàn)在如果有人惡意地構造幾個幾M大小的URL，
 并不停地訪問你的服務器。服務器的最大并發(fā)數(shù)顯然會下降。
 另一種攻擊方式是：把告訴服務器Content-Length是一個很大的數(shù)，
 然后只給服務器發(fā)一點兒數(shù)據(jù)，嘿嘿，服務器你就傻等著去吧。
 哪怕你有超時設置，這種故意的次次訪問超時也能讓服務器吃不了兜著走。
 有鑒于此，多數(shù)服務器出于安全啦、穩(wěn)定啦方面的考慮，會給URL長度加限制。
 但是這個限制是針對所有HTTP請求的，與GET、POST沒有關系。

GET所發(fā)送的數(shù)據(jù)是 URL 的一部分，
有時候會直接反應在瀏覽器的地址欄，
現(xiàn)在的瀏覽器大多會記住曾經輸入過的URL（在發(fā)送密碼或敏感信息時絕不要使用 GET ?。?br>試想如果你曾經在別人電腦上填過一個很私密的表單，那么你的這份記錄很可能被連沒什么電腦常識的人都一覽無遺。

但是被抓包之后的POST請求和GET請求是一樣裸露的，所以這里是相對的。

說 POST 比 GET 安全 也不完全對的。
根據(jù)HTTP規(guī)范，POST表示可能修改變服務器上的資源的請求。
在語義上（restful視角）:
GET的是獲取指定URL上的資源，是讀操作。
重要的一點是不論對某個資源GET多少次，它的狀態(tài)是不會改變的，
在這個意義上，我們說GET是安全的（不是被密碼學或者數(shù)據(jù)保護意義上的安全）。
因為GET是安全的，所以GET返回的內容可以被瀏覽器，Cache服務器緩存起來。

POST的語義是修改變服務器上的資源的請求，所以是不安全的，
每次提交的POST，代碼都會認為這個操作會修改資源的狀態(tài)，
于是，瀏覽器在你按下F5的時候會跳出確認框，緩存服務器不會緩存POST請求返回內容。

參考:
GET請求和POST請求的區(qū)別
不再以訛傳訛，GET和POST的真正區(qū)別 
淺談HTTP中Get與Post的區(qū)別
HTTP請求Get和Post的區(qū)別總結