HTTP 結構、狀態碼、首部簡記

HTTP

報文

HTTP報文包括3部分：

• 起始行
• 首部字段：名字和值以:區分，每一個首部字段以\r\n換行分割。首部以一個空行表示結束。
• 主體

請求報文起始行結構：

• 方法(method): GET是這個請求的方法。
• 請求URL(request-URL): 這個request所請求的資源。
• 版本(version): 請求報文所用的HTTP版本，格式爲HTTP/<major>.<minor>。

響應報文起始行結構：

• 版本(version):響應報文所用的HTTP版本，服務器應該返回相同的與請求相同的HTTP版本。
• 狀態碼(status-code): 這三位數描述的是請求過程的狀況。
• 緣由短語(reason-phrase): 狀態碼的可讀版本。

方法

GET

GET方法用於請求服務器發送某個資源。HTTP/1.1 要求服務器實現此方法。

HEAD

HEAD方法與GET方法相似，但服務器在響應只返回首部，不會返回實體的主體部分。這容許了客戶端在未獲取實際資源的狀況下，對資源的首部進行檢查。使用HEAD，能夠：

• 再不獲取資源的狀況下了解資源的狀況；
• 經過查看響應的狀態碼，檢查某個對象是否存在；
• 經過查看首部，測試資源是否被修改了；

服務器開發者必須確保返回的首部與GET請求所返回的首部徹底相同。HTTTP/1.1 要求服務器實現此方法。

PUT

與GET從服務器讀取文檔相反，PUT方法向服務器寫入文檔。PUT方法的語義就是讓服務器用請求的主體部分建立一個由所請求的URL命名的新文檔，若是，若是那個URL已經存在，就用這個主體替換它。

POST

POST方法是用來向服務器輸入數據的，一般用它來支持HTML的表單。

TRACE

TRACE請求會在目的服務器發起一個「環回」診斷。行程最後一站的服務器回彈回一條TRACE響應，並在響應的主圖中攜帶它受到的原始請求報文。這樣客戶端就能夠查看在全部中間HTTP應用程序組成的請求/響應鏈上，原始報文是否以及若是被毀壞活着修改。TRACE主要用於診斷。

缺點：TRACE假定中間應用程序對各類不一樣類型的請求（GET，HEAD，POST等）的處理是相同的，可是不少HTTP應用程序會根據方法的不一樣作出不一樣的處理。TRACE並不提供區分這些方法的機制。

TRACE請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應服務器收到的請求的精確副本。

OPTIONS

OPTIONS方法請求Web服務器告知其支持的各類功能。

DELETE

DELETE方法請求服務器刪除請求URL所指定的資源。

####其餘擴展方法

擴展方法是指沒有在HTTP/1.1規範中定義的方法。

常見的擴展方法

方法	描述
LOCK	容許用戶「鎖定」資源
MKCOL	容許用戶建立資源
COPY	便於在服務器上覆制資源
MOVE	在服務器上移動資源

狀態碼

100 ~ 199 信息狀態碼(HTTP/1.1中引入)

狀態碼	緣由短語	含義
100	Continue	說明收到請求的初始部分，請客戶端繼續。發送了這個狀態碼以後，服務器在收到請求以後必須進行響應。
101	Switching Protocols	說明服務器正在根據客戶端的指定，將協議切換到Update首部所列的協議。

100 Continue的目的是對這樣的狀況進行優化：HTTP客戶端應用程序有一個實體的主體部分要發送給服務器，但但願在發送以前查看一下服務器是否會接受這個實體。

• 客戶端與 100 Continue

若是客戶端在向服務器發送一個實體，而且願意在發送實體以前等待100 Continue響應，那麼，客戶端就要發送一個攜帶了值爲100 Continue的 Expect 請求首部。若是客戶端沒有發送實體，就不該該發送100 Continue Expect 首部，由於這樣會使服務器誤覺得客戶端要發送一個實體。

發送了100 Continue Expect 首部的客戶端，不該該永遠在等待服務器發送100 Continue響應。過期必定時間後，客戶端應該直接將實體發送吹起。實際上，客戶端程序也應該作好應對非預期100 Continue響應的準備。

• 服務器與 100 Continue

若是服務器收到一條帶有100 Continue Expect 首部的請求，它會用100 Continue響應或者一條錯誤代碼來進行響應。

若是服務器在有機會發送100 Continue響應以前收到了部分(或者所有)的實體，就說明客戶端已經決定繼續發送數據了，這樣，服務器就不須要發送這個100 Continue狀態碼了。但服務器讀完請求後，還會應該爲請求發送一個最終狀態碼（它能夠跳過100 Continue狀態）。

最後，若是服務器受到了100 Continue Expect 首部的請求，且在它決定讀取實體的主體部分以前結束請求，就不該該僅僅是發送一個響應並關閉鏈接，由於這個會妨礙客戶端接受響應。

• 代理與 100 Continue

若是代理從客戶端收到一個帶有100 Continue Expect 首部的請求，它須要作幾件事。若是代理知道下一跳服務器是HTTP/1.1兼容的，或者並不知道下一跳服務器與哪一個版本兼容，它都應該將 Expect 首部放在請求中向下轉發。若是它知道下一跳服務器只能與HTTP/1.1以前的版本兼容，就應該以417 Expectation Failed錯誤進行響應（另外一種合理方法是，向客戶端想返回100 Continue，在向服務器轉發請求時，刪掉 Expect 的首部）。

200 ~ 299 成功狀態碼

狀態碼	緣由短語	含義
200	OK	請求沒問題，實體的主體部分包含了全部的請求資源
201	Created	用於建立服務器對象的請求(好比，PUT)。響應的實體主體部分中應該包含各類飲用了已建立的資源的URL，Location 首部包含的則是最具體的引用。 服務器必須在發送這個狀態碼以前建立好對象。
202	Accepted	請求已被接受，但服務器還未對其執行任何動做，不能保證服務器會完成這個請求；這只是意味着接受請求時，它看起來是有效的。 服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計（或者包含一個指針，只想能夠獲取此信息的位置）。
203	Non-Authoritative Infomation	實體首部包含的信息不是來自源端服務器，而是來自資源的一份副本，若是中間節點上有一份資源副本，但沒法或者沒有對它所發送的與資源有關的元信息(首部)進行驗證，就會出現這種狀況。這個狀態碼不是非用不可，若是實體首部來自源端服務器，響應爲200狀態的應用程序就能夠將其做爲一種可選項使用。
204	No Content	響應報文中包含若干首部和一個狀態行，但沒有實體的主體部分。主要用於在瀏覽器不轉爲顯示新文檔的狀況下，對其進行更新(好比刷新一個表單頁面)。
205	Reset Content	另外一個主要用於瀏覽器的狀態碼，負責告知瀏覽器清楚當前頁面中的全部HTML表單元素。
206	Partial Content	成功執行一個部分或 Range(範圍) 請求。206響應中必須包含Content-Range、Date以及ETag或Content-Location首部。

300 ~ 399 重定向狀態碼

狀態碼	緣由短語	含義
300	Multiple Choices	客戶端請求一個實際指向多個資源的 URL 時會返回這個狀態碼，好比服務器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶着一個選項列表；這樣用戶就能夠選擇他但願使用的那一項了。有多個版本可用時，客戶端須要溝通解決。服務器能夠在 Location 首部包含首選 URL。
301	Moved Permanently	在請求的 URL 已被移除時使用。響應的 Location 首部中應該包含資源如今所處的URL。
302	Found	與 301 狀態碼相似；可是，客戶端應該使用 Location 首部給出的 URL 來臨時定位資源。未來的請求仍應該使用老的URL。
303	See Other	告知客戶端應該用另外一個 URL 來獲取資源。新的 URL 位於響應報文的 Location 首部。其主要目的是容許 POST 請求的響應將客戶端定向到某個資源上去。
304	Mot Modified	客戶端能夠經過所包含的請求首部，使其請求變成有條件的。若是客戶端發起一個條件 GET 請求，而最近資源未被修改的話，就能夠用這個狀態碼來講明資源未被修改。帶有這個狀態碼的響應不該該包含實體的主體部分。
305	Use Proxy	用來講明必須經過一個代理來訪問資源；代理的位置由 Location 首部給出。很重要一點是，客戶端是相對某個特定資源來解析這條響應的，不能假定全部請求，甚至全部對持有所請求資源的服務器的請求都經過這個代理進行。若是客戶端錯誤地讓代理介入了某條請求，可能會引起破壞性行爲，會形成安全漏洞。
306	(未被使用)	當前未使用。
307	Temporary Redirect	與301狀態碼相似；但客戶端應該使用 Location 首部給出的 URL 來臨時定位資源。未來的請求應該使用老的 URL。

302，303，307之間存在交叉，主要來之於 HTTP/1.0 和 HTTP/1.1 的處理方式不一樣。

當 HTTP/1.0 客戶端發起一個 POST 請求，並在響應中收到了 302 重定向狀態碼時，它會接受 Location 首部的重定向 URL，並向那個 URL 發起一個 GET 請求（而不會像原始請求中那樣發起一個 POST 請求）。

而在 HTTP/1.1 中，HTTP/1.1 規範使用 303 狀態碼來實現一樣的行爲（服務器發送 303 狀態碼來重定向客戶端的 POST 請求，在它後面跟上一個 GET 請求）。

爲了避開這個問題，HTTP/1.1 規範指出，對於 HTTP/1.1 客戶端，用 307 狀態碼取代302狀態碼來進行重定向。這樣服務器就能夠將 302 狀態碼保留起來，爲HTTP／1.0 客戶端使用。

400 ~ 499 客戶端錯誤代碼

狀態碼	緣由短語	含義
400	Bad Request	用於告知客戶端它發送了一個錯誤的請求
401	Unauthorized	與適當的首部一同返回，在這些首部中請求客戶端在獲取對資源的訪問權以前，對本身進行認證。
402	Payment Required	保留狀態碼
403	Forbidden	用於說明請求被服務器拒絕了。若是服務器想說明爲何拒絕請求，能夠包含實體的主體部分來對緣由進行描述。但這個狀態碼一般是用在服務器不想說明拒絕緣由的時候使用。
404	Not Found	用於說明服務器沒法找到所請求 URL。一般會包含一個實體，以便客戶端應用程序現實給用戶看。
405	Method Not Allowed	發起請求中帶有所請求的 URL 不支持的方法時，使用此狀態碼。應該在響應中包含 Allow 首部，以告知客戶端對所請求的資源可使用哪些方法。
406	Not Acceptable	客戶端能夠指定參數哦來講明它們願意接收什麼類型的實體。服務器沒有與客戶端能夠接受的 URL 相匹配的資料時，使用此代碼。一般，服務器會包含一些首部，以便客戶端弄清楚爲何請求沒法知足。
407	Proxy Authentication Required	與 401 狀態碼相似，但用於要求對資源進行認證的代理服務器。
408	Request Timeout	若是客戶端完成請求所花的時間太長，服務器可能回送此狀態碼，並關閉鏈接。超時時長隨服務器的不一樣有所不一樣，但一般對全部的合法請求來講，都是夠長的。
409	Conflict	用於說明請求可能在資源上引起的一些衝突。服務器擔憂請求會引起衝突時，能夠發送此狀態碼。響應中應該包含描述衝突的主體。
410	Gone	與 404 相似，只是服務器曾經擁有過此資源。主要用於 Web 站點的維護，這樣服務器的管理者就能夠在資源被移除的狀況下通知客戶端。
411	Length Required	服務器要求在請求報文中包含 Content-Length 首部使用。
412	Precondition Failed	客戶端發起了條件請求，且其中一個條件失敗了的時候使用。客戶端包含了 Expect 首部發起的就是條件請求。
413	Request Entity Too Large	客戶端發送的實體主體部分比服務器可以或者但願處理的要大時，使用此狀態碼。
414	Request URI Too Long	客戶端發送請求中的請求 URL 比服務器可以或者但願處理的要長時，使用此狀態碼。
415	Unsupported Media Type	服務器沒法理解或者沒法支持客戶端所發實體的內容類型時，使用此狀態碼。
416	Requested Range Not Satisfiable	請求報文所請求的是指定資源的某個範圍，而此範圍無效或者沒法知足時，使用此狀態。
417	Expectation Failed	請求的 Expect 請求首部包含了一個指望，但服務器沒法知足此指望時，使用此代碼。若是代理或者其餘中間應用程序由確切證聽說明源服務器會爲某請求產生一個失敗的指望，就能夠發送這個響應狀態碼。

500 ~599 服務器錯誤狀態碼

狀態碼	緣由短語	含義
500	Internal Server Error	服務器遇到一個妨礙它做爲請求提供服務的錯誤時，使用此狀態。
501	Not Implemented	客戶端發起的請求超過服務器能力範圍（好比，使用了服務器不支持的請求方法）時，使用此狀態。
502	Bad Gateway	做爲代理或網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應（好比，他沒法鏈接到父網關）時，使用此狀態。
503	Service Unavailabe	用來講明服務器如今沒法爲請求提供服務，但未來能夠。若是服務器知道何時資源會變爲可用的，能夠在響應中包含一個 Retry-After 首部。
504	Gateway Timeout	與狀態碼408相似，只是這裏的響應來自一個網關或代理，它們在等待裏一服務器對其請求進行響應超時了。
505	HTTP Version Not Supported	服務器收到的請求使用了它沒法或不肯支持的協議版本時，使用此狀態碼。有些服務器應用程序會選擇不支持早期版本的協議。

首部

####1.通用首部 有些首部時客戶端和服務端都能使用，且提供了與報文相關的最基本信息，叫作通用首部。

通用信息首部

首部	描述
Connection	容許客戶端和服務器指定與請求/響應鏈接有關的選項。
Date	提供日期和時間標誌，說明報文是什麼時間建立的。
MIME-Version	給出了發送短使用的 MINE 版本。
Trailer	若是報文采用了分塊傳輸編碼(chunked transfer encoding)方式，就能夠用這個首部列出位於報文拖掛(trailer)部分的首部集合。
Transfer-Encoding	告知接收端爲了保證報文的可靠傳輸，對報文采用了什麼編碼方式。
Update	給出了發送端可能想要"升級"使用的新版本或協議。
Via	顯示報文通過的中間節點（代理、網關）。

通用緩存首部

首部	描述
Cache-Control	用於隨報文傳送緩存指示。
Pragma	另外一種隨報文傳送指示的方式，當並不專用於緩存。

####2.請求首部

請求首部是隻在請求報文中有意義的首部。

請求的信息性首部

首部	描述
Client-IP	提供了運行客戶端的機器的IP地址。
From	提供了客戶端用戶的 Email 地址。（使用RFC 822 E-mail地址格式）
Host	給出了接受請求的服務器的主機名和端口號。
Referer	提供了包含當前請求 URI 的文檔的 URL。
UA-Color	提供了與客戶端顯示器的現實顏色有關的信息。
UA-CPU	提供了客戶端 CPU 的類型和製造商。
UA-Disp	提供了與客戶端顯示器能力有關的信息。
UA-OS	給出了運行在客戶端機器上的操做系統名稱和版本。
UA-Pixels	提供了客戶端顯示器的色素信息。
User-Agent	將發起請求的應用程序名告知服務器。

Accept首部

Accept首部爲客戶端提供了一種將其喜愛和能力告知服務器的方式。Accept首部會使鏈接的兩端都受益。

首部	描述
Accept	告訴服務器可以發送哪些媒體類型。
Accept-Charset	告訴服務器可以發送哪些字符集。
Accept-Encoding	告訴服務器可以發送哪些編碼方式。
Accept-Language	告訴服務器可以發送哪些語言。
TE	告訴服務器可使用哪些擴咱傳輸編碼。

條件請求首部

有時客戶端但願爲請求加上某些限制。好比，客戶端已經有了一份文檔副本，就但願只在服務器上的文檔與客戶端擁有的副本有區別時，才請求服務器傳輸文檔。經過條件請求首部，客戶端就能夠爲請求加上這種限制，要求服務器在對請求進行響應以前，確保某個條件爲真。

首部	描述
Expect	容許客戶端列出請求所要求的服務器行爲。
If-Match	若是實體標記與文檔當前的實體標記相匹配，就獲取這份文檔。
If-Modified-Since	除非在某個指定的日期以後資源被修改過，不然就限制這個請求。
If-None-Match	若是提供的實體標記與當前文檔的實體標記不相符，就獲取文檔。
If-Range	容許對文檔的某個範圍進行條件請求。
If-Unmodified-Since	除非在某個指定日期以後資源沒有被修改過，不然限制這個請求。
Range	若是服務器支持範圍請求，就請求資源的指定範圍。

安全請求首部

首部	描述
Authorization	包含了提供給服務器來對客戶端進行自身認證的數據。
Cookie	客戶端用它向服務器傳送一個令牌-----它並非真正的安全首部，但倒是隱含了安全功能。
Cookie2	用來講明請求端支持的cookie版本。

代理請求首部

首部	描述
Max-Forward	在通往源端服務器的路徑上，將請求轉發給其餘代理或網管的最大次數----與 TRACE 方法一同使用。
Proxy-Authorization	與 Authorization 首部相同，但這個首部是在於代理進行認證時使用的。
Proxy-Connection	與 Connection 首部相同，但這個首部是在於代理創建鏈接時使用的。

####3.響應首部

#####響應的信息性首部

首部	描述
Age	（從最初建立開始)響應持續時間。
Public	服務器爲其資源支持的請求方法列表。
Retry-After	若是資源不可用的話，在此日期或時間重試。
Server	服務器應用程序軟件的名稱和版本。
Title	對 HTML 文檔來講，就是 HTML 文檔的源端給出的標題。
Warning	比緣由短語更詳細一些的警告報文。

#####協商首部

首部	描述
Accept-Ranges	對此資源來講，服務器可接受的範圍類型。
Vary	服務器查看的其餘首部列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最適合的資源版本發送給客戶端。

#####安全響應首部

首部	描述
Proxy-Authenticate	來自代理的對客戶端的質詢列表。
Set-Cookie	不是真正的安全首部，但隱含安全功能；能夠在客戶端設置一個令牌，以便服務器對其客戶端進行標識。
Set-Cookie2	與 Set-Cookie 相似，PFC 2965 Cookie定義。
WWW-Authenticate	來自服務器對客戶端的質詢列表。

####4.實體首部

實體首部提供了有關實體及其內容的大量信息，請求和響應報文中均可能包含實體部分，因此這兩類報文均可能出現這些首部。總之，實體首部能夠告知報文的接收者它在對什麼進行處理。

#####實體的信息性首部

首部	描述
Allow	列出能夠對此事提執行的請求方法。
Location	告知客戶端實際上位於何處；用於將接收端定向到資源的(多是新的)位置(URL)上去。

#####內容首部

內容首部提供了與實體內容有關的特定信息，說明了其類型，尺寸以及處理它所須要的其它有用信息。

首部	描述
Content-Base	解釋主體中的相對 URL 時使用的基礎 URL
Content-Encoding	對主體執行的任意編碼方式。
Content-Language	理解主體時最適宜使用的天然語言。
Content-Length	主體的長度或尺寸。
Content-Locaton	資源實際所處的位置。
Content-MD5	主體的 MD5 校驗和。
Content-Range	在整個資源中此實體表示的字節範圍。
Content-Type	在這個主體的對象類型。

#####實體緩存首部

通用的緩存首部說明了如何或者何時進行緩存。實體的緩存首部提供了與被緩存實體有關的信息。

首部	描述
ETag	與此實體相關的實體標記。
Expires	實體再也不有效，要從原始的源端再次獲取此實體的日期和時間。
Last-Modified	這個實體最後一次被修改的日期和時間。