一，一般現在流傳的HTTP請求：GET和POST的比較是這樣的：

GET和POST是HTTP的兩個常用方法。

什麼是HTTP?

超文字傳輸協議(HyperText Transfer Protocol -- HTTP)是一個設計來使客戶端和伺服器順利進行通訊的協議。

HTTP在客戶端和伺服器之間以request-responseprotocol（請求-回覆協議）工作。

GET- 從指定的伺服器中獲取資料

POST- 提交資料給指定的伺服器處理

GET方法：

使用GET方法時，查詢字串（鍵值對）被附加在URL地址後面一起傳送到伺服器：

/test/demo_form.jsp?name1=value1&name2=value2

特點：

·        GET請求能夠被快取

·        GET請求會儲存在瀏覽器的瀏覽記錄中

·        以GET請求的URL能夠儲存為瀏覽器書籤

·        GET請求有長度限制

·        GET請求主要用以獲取資料

POST方法：

使用POST方法時，查詢字串在POST資訊中單獨存在，和HTTP請求一起傳送到伺服器：

POST/test/demo_form.jsp HTTP/1.1

Host:w3schools.com

name1=value1&name2=value2

特點：

·        POST請求不能被快取下來

·        POST請求不會儲存在瀏覽器瀏覽記錄中

·        以POST請求的URL無法儲存為瀏覽器書籤

·        POST請求沒有長度限制

GET和POST的區別：

其他HTTP請求方式

1. GET和POST與資料如何傳遞沒有關係

GET和POST是由HTTP協議定義的。在HTTP協議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪個Method與應用層的資料如何傳輸是沒有相互關係的。

HTTP沒有要求，如果Method是POST資料就要放在BODY中。也沒有要求，如果Method是GET，資料（引數）就一定要放在URL中而不能放在BODY中。

那麼，網上流傳甚廣的這個說法是從何而來的呢？我在HTML標準中，找到了相似的描述。這和網上流傳的說法一致。但是這只是HTML標準對HTTP協議的用法的約定。怎麼能當成GET和POST的區別呢？

而且，現代的Web Server都是支援GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發出，但是現在的Web Server又不是隻給瀏覽器用，已經完全地超出了HTML伺服器的範疇了。

2. HTTP協議對GET和POST都沒有對長度的限制

HTTP協議明確地指出了，HTTP頭和Body都沒有長度的要求。而對於URL長度上的限制，有兩方面的原因造成：

1.    瀏覽器。據說早期的瀏覽器會對URL長度做限制。據說IE對URL長度會限制在2048個字元內（流傳很廣，而且無數同事都表示認同）。但我自己試了一下，我構造了90K的URL通過IE9訪問live.com，是正常的。網上的東西，哪怕是Wikipedia上的，也不能信。

2.   伺服器。URL長了，對伺服器處理也是一種負擔。原本一個會話就沒有多少資料，現在如果有人惡意地構造幾個幾M大小的URL，並不停地訪問你的伺服器。伺服器的最大併發數顯然會下降。另一種攻擊方式是，把告訴伺服器Content-Length是一個很大的數，然後只給伺服器發一點兒資料，嘿嘿，伺服器你就傻等著去吧。哪怕你有超時設定，這種故意的次次訪問超時也能讓伺服器吃不了兜著走。有鑑於此，多數伺服器出於安全啦、穩定啦方面的考慮，會給URL長度加限制。但是這個限制是針對所有HTTP請求的，與GET、POST沒有關係。

安全不安全和GET、POST沒有關係

我覺得這真是中國特色。我講個小段子，大家應該可以體會出這個說法多麼的可笑。

覺得POST資料比GET資料安全的人會說

“防君子不防小人；中國小白多，能防小白使用者就行了。”

“哼，”我不以為然，“那你怎麼不說，URL引數都Encode過了，或是Base64一下，小白也看不懂啊。”

那人反駁道，“Encode太簡單了，聰明點兒的小白很容易就可以Decode並修改掉。”

我笑道，“五十步笑百步耳，再聰明點兒的小白還會截包並重發呢，Opera就有這功能。”

那人陰險地祭出神器——最終解釋權，說，“這個不算小白。”

我日啊。