GET和POST有什麼區別？及為什麼網上的多數答案都是錯的

標籤：

如果有人問你，GET和POST，有什麼區別？你會如何回答？

最普遍的答案

     回來之後尋思了很久，他到底是想問我什嗎？我一直就覺得GET和POST沒有什麼除了語義之外的區別，自打我開始學習Web編程開始就是這麼理解的。

     可能很多人都已經猜到了，他要的答案是：

1. GET使用URL或Cookie傳參。而POST將資料放在BODY中。

2. GET的URL會有長度上的限制，則POST的資料則可以非常大。

3. POST比GET安全，因為資料在地址欄上不可見。

     但是很不幸，這些區別全是錯誤的，更不幸的是，這個答案還是Google搜尋的頭版頭條，然而我根本沒想著這些是答案，因為在我看來他們都是錯的。我來一一解釋一下。

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伺服器的範疇了。

     知道這個有什麼用？我不想解釋了，有時候就得自己痛一次才記得住。

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就有這功能。”

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

     我日啊。

GET和POST有什麼區別？及為什麼網上的多數答案都是錯的