（三）GET和POST協議詳解
一、GET請求報文分析：
1、 請求行：
a) GET（描述該請求采用了什麽請求方法），HTTP協議中包含8種請求方法：
-
- GET 請求獲取Request-URI 所標識的資源
- POST 在Request-URI 所標識的資源後附加新的數據
- HEAD 請求獲取由Request-URI 所標識的資源的響應消息報頭
- PUT 請求服務器存儲一個資源，並用Request-URI 作為其標識
- DELETE 請求服務器刪除Request-URI 所標識的資源
- TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
- CONNECT 保留將來使用
- OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求
b) URI（請求WEB服務器的資源名稱）
(一) URI：統一資源標識符（代表這個資源的名稱），如：上圖中的 /PrjTheHttpProtocol/test?username=admin&userpassword=123
說明：HTTP協議規定GET請求發送數據在URI中發送，格式：uri?name=value&name=value&name=value…..
(二) URL：統一資源定位符（不但代表這個資源的名稱，而且通過它還可以找到該資源），如：http://ip:port/URI
c) HTTP1.1（當前使用的HTTP協議版本）
2、請求報頭
a) 告訴web服務器瀏覽器接收的語言版本
b) 請求web服務器的IP地址和端口號
c) Cookies等信息
3、空白行（分割請求報頭和請求體的專用行）
4、請求體（由於當前使用的請求方式是GET請求方式，所以請求體中不傳送任何數據）
二、POST請求報文分析：
1、 請求行：
a) 上圖采用POST方式發送請求。
b) 上圖URI後邊沒有任何數據，這是因為采用POST方式提交的緣故。
c) HTTP1.1（當前使用的HTTP協議版本）
2、 請求報頭（由於請求是POST請求，所以報頭中顯示：Cache-Control：no-cache）
3、 空白行
4、 請求體（由於當前使用的請求方式是POST請求方式，所以數據在請求體中發送，並且格式是：name=value&name=value&name=value……）
三、響應報文分析：
1、 狀態行
a) HTTP1.1 ： HTTP協議版本號
b) 200 ： 響應狀態號
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
常見狀態代碼、狀態描述、說明：
200 OK 客戶端請求成功
400 Bad Request 客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized 請求未經授權
403 Forbidden 服務器收到請求，但是拒絕提供服務
404 Not Found 請求資源不存在
405 瀏覽器客戶端發送的請求和底層的方法doPost/doGet不一致導致的。
500 Internal Server Error 服務器發生不可預期的錯誤
503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間後， 可能恢復正常。
c) OK ： 對響應結果的描述
2、 響應報頭
a) WEB服務器版本信息
b) 內容類型以及字符編碼方式
c) 內容長度，響應回來的總字符數
d) 響應時間
e) Cookies等信息
3、 空白行（分割響應報頭和響應體的專用行）
4、 響應體：響應正文（從WEB服務器端響應回來的HTML代碼）
四、HTTP請求中GET和POST的區別
HTTP請求的兩種方式，GET和POST請求的表現形式上的區別：
- GET請求通過URL（請求行）提交數據，在URL中可以看到所傳參數。POST通過“請求體”傳遞數據，參數不會在URL中顯示 。
- GET請求提交的數據有長度限制（1024或2048），POST請求沒有限制（或限制80KB）。
- GET請求返回的內容可以被瀏覽器緩存起來。而每次提交的POST，瀏覽器在你按下F5的時候會跳出確認框，瀏覽器不會緩存POST請求返回的內容。
以上描述都是GET，POST兩者區別表現形式，是瀏覽器對這兩種請求的處理方式。
HTTP請求的兩種方式，GET和POST請求的本質上的區別：
HTTP協議是這樣解釋GET和POST的：GET請求不應該做讀取數據之外的事情。而如果一個請求，修改了服務器資源或者使用了服務器資源（如發郵件，使用打印機等），那麽應當使用POST。所以，GET和POST的本質區別是使用場景的區別，簡單的說，GET是只讀，POST是寫。瀏覽器對兩種請求的不同處理方式也是基於這兩個不同的場景：
- GET：查詢往往需要的上傳的數據量比較小，查詢參數也往往不需要保密，所以放在URL裏比較高效。HTTP協議要求同一URL的多個請求應該返回同樣的結果，所以瀏覽器可以把返回結果緩存起來，以提高性能。至於參數長度的限制，這個是和瀏覽器URL的長度限制相關的，1024也好，2048也好，其實沒有太大的意義，參數超長往往是錯誤使用GET方法的結果。
- POST：修改數據需要支持大數據量表單的提交，數據也常常包含用戶的私人信息，所以數據放在請求的消息體中傳遞。相同的POST請求可能會對服務器端產生不同的影響，比如兩次POST可能創建兩條不同的數據，所以對POST返回結果的緩存是沒有意義的。
用GET，還是用POST？
如果回答“因為POST的參數長度不受限制，所以我用POST，就有點本末倒置了。兩者之間如何選擇，首先要看是不是修改或者使用了服務器資源，其次要看請求或者響應中的數據是不是包含了敏感信息，如果是，那麽應該選擇POST，同時處於安全性的考慮，服務器端應該只接受POST，拒絕GET。比如數據的增加和修改，認證信息的提交，是一定要用POST的。如果只是簡單查詢，用GET就可以了。
POST請求是不是比GET請求更安全？
有人說“POST比GET安全，因為GET的參數都明文寫在URL上了”，從個人信息安全的角度上說，這句話是對的，但這種安全機制是“防君子不防小人”的，有各種工具能夠獲取POST請求的數據。如前面所說，兩者有截然不同的使用場景，如果是該用POST的地方用了GET，又說GET不安全，那GET也太冤枉了。其實，HTTP協議中提到GET是安全的方法（safe method），其意思是說GET方法不會改變服務器端數據，所以不會產生副作用。這是建立在Web開發人員正確使用GET方法的基礎上的，如果修改數據的請求卻使用了GET方法，顯然是非常危險的。
GET與POST的誤用有什麽危害？
應該使用GET的地方用了POST：性能受損，瀏覽器不會緩存。
應該使用POST的地方用了GET：每一個這樣的地方都是一個漏洞，有可能被黑客利用。如果是一個對安全要求很高的網站，一定不要忽視。
不僅僅是在前端要正確的使用GET和POST，同時還需要後端代碼的支持，比如後端應當在需要POST請求的時候拒絕GET請求，從而切斷黑客利用GET請求攻擊的途徑，更高級別的，還需要對POST請求進行過濾，以確保所有的POST請求都來自可信任的地址。
如何判斷當前請求是GET請求還是POST請求？
- 在瀏覽器地址欄上直接編寫URL提交的請求一定是GET請求。
- 使用熱鏈接向服務器發送的請求一定是GET請求。
- 使用form表單提交數據的時候，如果method屬性沒有編寫，或者method屬性值被指定是GET，這樣發送的請求屬於GET請求。
- 使用form表單提交數據的時候，如果method屬性值被手動指定為POST，那麽該請求屬於POST請求。
（三）GET和POST協議詳解