說說GET和POST方法的區別

徹底來自博客園的一篇文章,GET和POST有什麼區別?說的很是有道理,學習了.html

錯誤理解 反駁
GET使用URL或Cookie傳參。而POST將數據放在BODY中。 GET和POST與數據如何傳遞沒有關係
GET的URL會有長度上的限制,則POST的數據則能夠很是大。 HTTP協議對GET和POST都沒有對長度的限制
POST比GET安全,由於數據在地址欄上不可見。 安全不安全和GET、POST沒有關係

文章做者的理解——編程

對於GET和POST的理解,是純粹地來源於HTTP協議。他們只有一點根本區別,簡單點兒說,一個用於獲取數據,一個用於修改數據。具體的請參考RFC文檔。瀏覽器

引入原文吧,確實很贊——安全

若是有人問你,GET和POST,有什麼區別?你會如何回答?服務器

  個人經歷

  前幾天有人問我這個問題。我說GET是用於獲取數據的,POST,通常用於將數據發給服務器之用。併發

  這個答案好像並非他想要的。因而他繼續追問有沒有別的區別?我說這就是個名字而已,若是服務器支持,他徹底能夠把GET改個名字叫GET2。他反問道,那就是單純的名字上的區別嘍?我想了想,我以爲若是說再具體的區別,只能去看RFC文檔了,還要取決於服務器(指Apache,IIS)的具體實現。但我不得不認可,個人確沒有仔細看過HTTP的RFC文檔。因而我說,我對HTTP協議不太熟悉。這個問題也就結束了。post

  最廣泛的答案

  回來以後尋思了好久,他究竟是想問我什麼?我一直就以爲GET和POST沒有什麼除了語義以外的區別,自打我開始學習Web編程開始就是這麼理解的。學習

  可能不少人都已經猜到了,他要的答案是:google

  1. GET使用URL或Cookie傳參。而POST將數據放在BODY中。firefox

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

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

  我日啊。

  最後一點兒感想

  我以前一直作Windows桌面應用,對Web開發無甚瞭解,直到一年多前轉作服務器端開發,纔開始接觸到HTTP。(注意,我說的是HTTP,不是HTML。服務器開放接口是基於REST理念設計的,使用的協議是HTTP,可是傳輸的內容不是HTML。這不是Web Server,而是一個Web Service)

  因此我對於GET和POST的理解,是純粹地來源於HTTP協議。他們只有一點根本區別,簡單點兒說,一個用於獲取數據,一個用於修改數據。具體的請參考RFC文檔。

  若是一我的一開始就作Web開發,極可能把HTML對HTTP協議的使用方式,當成HTTP協議的惟一的合理使用方式。從而犯了以偏概全的錯誤。

  可能有人會以爲我鑽牛角尖。我只是不喜歡模棱兩可,不喜歡邊界不清、概念不明,不喜歡「拿來主義」,也不喜歡被其它喜歡鑽牛角尖的人奚落得無地自容。

  「知之爲知之,不知爲不知,是知也。」

 但願對你們有所幫助.

相關文章
相關標籤/搜索