HTTP請求報文格式:

HTTP請求報文主要由請求行、首部行、請求正文3部分組成

1，請求行

由3部分組成，分別為：請求方法、URL（見備註1）以及協議版本，之間由空格分隔

請求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及擴充套件方法，當然並不是所有的伺服器都實現了所有的方法，部分方法即便支援，處於安全性的考慮也是不可用的。

方法欄位

①GET:請求獲取Request-URI(URI:通用資源識別符號,URL是其子集，URI注重的是標識，而URL強調的是位置，可以將URL看成原始的URI),所標識的資源。

最常見的一種請求方式，當客戶端要從伺服器中讀取文件時，當點選網頁上的連結或者通過在瀏覽器的位址列輸入網址來瀏覽網頁的，使用的都是GET方式

地址中”?”之後的部分就是通過GET傳送的請求資料，我們可以在位址列中清楚的看到，各個資料之間用”&”符號隔開。顯然，這種方式不適合傳送私密資料。另外，由於不同的瀏覽器對地址的字元限制也有所不同，一般最多隻能識別1024個字元，所以如果

②POST：在Request-URI所標識的資源後附加新的資料；支援HTML表單提交，表單中有使用者添入的資料，這些資料會發送到伺服器端，由伺服器儲存至某位置（例如傳送處理程式）

對於上面提到的不適合使用GET方式的情況，可以考慮使用POST方式，因為使用POST方法可以允許客戶端給伺服器提供資訊較多。POST方法將請求引數封裝在HTTP請求資料中，以名稱/值的形式出現，可以傳輸大量資料，這樣POST方式對傳送的資料大小沒有限制，而且也不會顯示在URL中。

③HEAD:請求Request-URI所標識的資源響應訊息報頭，HEAD方法可以在響應時不返回訊息體。

④PUT：與GET相反，請求伺服器儲存一個資源，並用Request-URI做為其標識；例如釋出系統。

⑤DELETE：請求刪除URL指向的資源

⑦TRACE：跟蹤請求要經過的防火牆、代理或閘道器等，主要用於測試或診斷

⑧CONNECT保留將來使用

協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1

2，請求頭部

請求頭部為請求報文添加了一些附加資訊，由“名/值”對組成，每行一對，名和值之間使用冒號分隔

常見請求頭如下：

請求頭部的最後會有一個空行，表示請求頭部結束，接下來為請求正文，這一行非常重要，必不可少

3，請求正文

可選部分，比如GET請求就沒有請求正文

GET請求示例：

POST請求示例：

HTTP響應報文格式:

HTTP響應報文主要由狀態行、響應頭部、響應正文3部分組成

1，狀態行

由3部分組成，分別為：協議版本，狀態碼，狀態碼描述，之間由空格分隔

狀態碼為3位數字：

200~299的狀態碼錶示成功；

300~399的狀態碼指資源重定向；

400~499的狀態碼指客戶端請求出錯；

500~599的狀態碼指服務端出錯（HTTP/1.1向協議中引入了資訊性狀態碼，範圍為100~199）

常遇到的狀態碼說明：

2，響應頭部

與請求頭部類似，為響應報文添加了一些附加資訊

常見響應頭部如下：

響應示例：

PS：

1，URI、URL和URN之間的區別

URI全名為Uniform Resource Indentifier（統一資源標識），用來唯一的標識一個資源，是一個通用的概念，URI由兩個主要的子集URL和URN組成

URL全名為Uniform Resource Locator（統一資源定位），通過描述資源的位置來標識資源

URN全名為Uniform Resource Name（統一資源命名），通過資源的名字來標識資源，與其所處的位置無關，這樣即使資源的位置發生變動，其URN也不會變化

HTTP規範將更通用的概念URI作為其資源識別符號，但是實際上，HTTP應用程式處理的只是URI的URL子集

關於HTTP請求GET和POST的區別

1.GET提交，請求的資料會附在URL之後（就是把資料放置在HTTP協議頭＜request-line＞中），以?分割URL和傳輸資料，多個引數用&連線;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果資料是英文字母/數字，原樣傳送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進製表示的ASCII。

POST提交：把提交的資料放置在是HTTP包的包體＜request-body＞中。

因此，GET提交的資料會在位址列中顯示出來，而POST提交，位址列不會改變

2.傳輸資料的大小：

   首先宣告,HTTP協議沒有對傳輸的資料大小進行限制，HTTP協議規範也沒有對URL長度進行限制。 而在實際開發中存在的限制主要有：

   GET:特定瀏覽器和伺服器對URL長度有限制，例如IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於作業系統的支援。

   因此對於GET提交時，傳輸資料就會受到URL長度的限制。

   POST:由於不是通過URL傳值，理論上資料不受限。但實際各個WEB伺服器會規定對post提交資料大小進行限制，Apache、IIS6都有各自的配置。

3.安全性：

    POST的安全性要比GET的安全性高。注意：這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作資料修改，而這裡安全的含義是真正的Security的含義，比如：通過GET提交資料，使用者名稱和密碼將明文出現在URL上，因為(1)登入頁面有可能被瀏覽器快取， (2)其他人檢視瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了。