不再以訛傳訛,GET和POST的真正區別

網上的多數答案都是錯的
服務器君一共花費了122.033 ms進行了5次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

如果有人問你,GET和POST,有什么區別?你會如何回答?

我的經歷

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

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

最普遍的答案

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

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

  1. GET使用URL或Cookie傳參。而POST將數據放在BODY中。
  2. GET的URL會有長度上的限制,則POST的數據則可以非常大。
  3. POST比GET安全,因為數據在地址欄上不可見。

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

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

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

我日啊。

最后一點兒感想

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

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

如果一個人一開始就做Web開發,很可能把HTML對HTTP協議的使用方式,當成HTTP協議的唯一的合理使用方式。從而犯了以偏概全的錯誤。

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

“知之為知之,不知為不知,是知也。”

本文地址:http://www.snpmgr.live/librarys/veda/detail/1919,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.snpmgr.live/librarys/veda/detail/1919

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《代碼整潔之道》 馬丁(Robert C. Martin) (作者), 韓磊 (譯者)

軟件質量,不但依賴于架構及項目管理,而且與代碼質量緊密相關。這一點,無論是敏捷開發流派還是傳統開發流派,都不得不承認。《代碼整潔之道》提出一種觀念:代碼質量與其整潔度成正比。干凈的代碼,既在質量上較為可靠,也為后期維護、升級奠定了良好基礎。作為編程領域的佼佼者,《代碼整潔之道》作者給出了一系列行之有效的整潔代碼操作實踐。這些實踐在《代碼整潔之道》中體現為一條條規則(或稱“啟示”),并輔以來自現實項目的正、反兩面的范例。只要遵循這些規則,就能編寫出干凈的代碼,從而有效提升代碼質量。

更多計算機寶庫...

燃烧吧足球登陆 吉林11选5遗漏 体彩七星彩走势图预测 pk10人工计划交流群 股票配资业务员怎么找客户 加拿大快乐8最快开奖 湖南幸运赛车2018开奖直播 乐开棋牌下载手机版 我摆摊卖饰品不赚钱怎么办 定独胆公式 青鹏棋牌游戏大厅下载 乐享购优惠券怎么返利赚钱 加拿大28 白山棋牌在线 加拿大快乐8技巧 贵州十一选五走势图手机 永利棋牌最新官方app下载