HTTP
報文
HTTP報文包括3部分：
- 起始行
- 首部字段：名字和值以
:區(qū)分，每個首部字段以\r\n換行分割。首部以一個空行表示結(jié)束。 - 主體
請求報文起始行結(jié)構(gòu)：
- 方法(method): GET是這個請求的方法。
- 請求URL(request-URL): 這個request所請求的資源。
- 版本(version): 請求報文所用的HTTP版本，格式為
HTTP/<major>.<minor>。
響應(yīng)報文起始行結(jié)構(gòu)：
- 版本(version):響應(yīng)報文所用的HTTP版本，服務(wù)器應(yīng)該返回相同的與請求相同的HTTP版本。
- 狀態(tài)碼(status-code): 這三位數(shù)描述的是請求過程的情況。
- 原因短語(reason-phrase): 狀態(tài)碼的可讀版本。
方法
GET
GET方法用于請求服務(wù)器發(fā)送某個資源。HTTP/1.1 要求服務(wù)器實現(xiàn)此方法。
HEAD
HEAD方法與GET方法類似，但服務(wù)器在響應(yīng)只返回首部，不會返回實體的主體部分。這允許了客戶端在未獲取實際資源的情況下，對資源的首部進(jìn)行檢查。使用HEAD，可以：
- 再不獲取資源的情況下了解資源的情況；
- 通過查看響應(yīng)的狀態(tài)碼，檢查某個對象是否存在；
- 通過查看首部，測試資源是否被修改了；
服務(wù)器開發(fā)者必須確保返回的首部與GET請求所返回的首部完全相同。HTTTP/1.1 要求服務(wù)器實現(xiàn)此方法。
PUT
與GET從服務(wù)器讀取文檔相反，PUT方法向服務(wù)器寫入文檔。PUT方法的語義就是讓服務(wù)器用請求的主體部分創(chuàng)建一個由所請求的URL命名的新文檔，如果，如果那個URL已經(jīng)存在，就用這個主體替換它。
POST
POST方法是用來向服務(wù)器輸入數(shù)據(jù)的，通常用它來支持HTML的表單。
TRACE
TRACE請求會在目的服務(wù)器發(fā)起一個“環(huán)回”診斷。行程最后一站的服務(wù)器回彈回一條TRACE響應(yīng)，并在響應(yīng)的主圖中攜帶它受到的原始請求報文。這樣客戶端就可以查看在所有中間HTTP應(yīng)用程序組成的請求/響應(yīng)鏈上，原始報文是否以及如果被毀壞活著修改。TRACE主要用于診斷。
缺點：TRACE假定中間應(yīng)用程序?qū)Ω鞣N不同類型的請求（GET，HEAD，POST等）的處理是相同的，但是很多HTTP應(yīng)用程序會根據(jù)方法的不同做出不同的處理。TRACE并不提供區(qū)分這些方法的機(jī)制。
TRACE請求中不能帶有實體的主體部分。TRACE響應(yīng)的實體主體部分包含了響應(yīng)服務(wù)器收到的請求的精確副本。
OPTIONS
OPTIONS方法請求Web服務(wù)器告知其支持的各種功能。
DELETE
DELETE方法請求服務(wù)器刪除請求URL所指定的資源。
其他擴(kuò)展方法
擴(kuò)展方法是指沒有在HTTP/1.1規(guī)范中定義的方法。
常見的擴(kuò)展方法
| 方法 | 描述 |
|---|---|
| LOCK | 允許用戶“鎖定”資源 |
| MKCOL | 允許用戶創(chuàng)建資源 |
| COPY | 便于在服務(wù)器上復(fù)制資源 |
| MOVE | 在服務(wù)器上移動資源 |
狀態(tài)碼
100 ~ 199 信息狀態(tài)碼(HTTP/1.1中引入)
| 狀態(tài)碼 | 原因短語 | 含義 |
|---|---|---|
| 100 | Continue | 說明收到請求的初始部分，請客戶端繼續(xù)。發(fā)送了這個狀態(tài)碼之后，服務(wù)器在收到請求之后必須進(jìn)行響應(yīng)。 |
| 101 | Switching Protocols | 說明服務(wù)器正在根據(jù)客戶端的指定，將協(xié)議切換到Update首部所列的協(xié)議。 |
100 Continue的目的是對這樣的情況進(jìn)行優(yōu)化：HTTP客戶端應(yīng)用程序有一個實體的主體部分要發(fā)送給服務(wù)器，但希望在發(fā)送之前查看一下服務(wù)器是否會接受這個實體。
- 客戶端與
100 Continue
如果客戶端在向服務(wù)器發(fā)送一個實體，并且愿意在發(fā)送實體之前等待100 Continue響應(yīng)，那么，客戶端就要發(fā)送一個攜帶了值為100 Continue的 Expect 請求首部。如果客戶端沒有發(fā)送實體，就不應(yīng)該發(fā)送100 Continue Expect 首部，因為這樣會使服務(wù)器誤以為客戶端要發(fā)送一個實體。
發(fā)送了100 Continue Expect 首部的客戶端，不應(yīng)該永遠(yuǎn)在等待服務(wù)器發(fā)送100 Continue響應(yīng)。過時一定時間后，客戶端應(yīng)該直接將實體發(fā)送吹起。實際上，客戶端程序也應(yīng)該做好應(yīng)對非預(yù)期100 Continue響應(yīng)的準(zhǔn)備。
- 服務(wù)器與
100 Continue
如果服務(wù)器收到一條帶有100 Continue Expect 首部的請求，它會用100 Continue響應(yīng)或者一條錯誤代碼來進(jìn)行響應(yīng)。
如果服務(wù)器在有機(jī)會發(fā)送100 Continue響應(yīng)之前收到了部分(或者全部)的實體，就說明客戶端已經(jīng)決定繼續(xù)發(fā)送數(shù)據(jù)了，這樣，服務(wù)器就不需要發(fā)送這個100 Continue狀態(tài)碼了。但服務(wù)器讀完請求后，還會應(yīng)該為請求發(fā)送一個最終狀態(tài)碼（它可以跳過100 Continue狀態(tài)）。
最后，如果服務(wù)器受到了100 Continue Expect 首部的請求，且在它決定讀取實體的主體部分之前結(jié)束請求，就不應(yīng)該僅僅是發(fā)送一個響應(yīng)并關(guān)閉連接，因為這個會妨礙客戶端接受響應(yīng)。
- 代理與
100 Continue
如果代理從客戶端收到一個帶有100 Continue Expect 首部的請求，它需要做幾件事。如果代理知道下一跳服務(wù)器是HTTP/1.1兼容的，或者并不知道下一跳服務(wù)器與哪個版本兼容，它都應(yīng)該將 Expect 首部放在請求中向下轉(zhuǎn)發(fā)。如果它知道下一跳服務(wù)器只能與HTTP/1.1之前的版本兼容，就應(yīng)該以417 Expectation Failed錯誤進(jìn)行響應(yīng)（另一種合理方法是，向客戶端想返回100 Continue，在向服務(wù)器轉(zhuǎn)發(fā)請求時，刪掉 Expect 的首部）。
200 ~ 299 成功狀態(tài)碼
| 狀態(tài)碼 | 原因短語 | 含義 |
|---|---|---|
| 200 | OK | 請求沒問題，實體的主體部分包含了所有的請求資源 |
| 201 | Created | 用于創(chuàng)建服務(wù)器對象的請求(比如，PUT)。響應(yīng)的實體主體部分中應(yīng)該包含各種飲用了已創(chuàng)建的資源的URL，Location 首部包含的則是最具體的引用。 服務(wù)器必須在發(fā)送這個狀態(tài)碼之前創(chuàng)建好對象。 |
| 202 | Accepted | 請求已被接受，但服務(wù)器還未對其執(zhí)行任何動作，不能保證服務(wù)器會完成這個請求；這只是意味著接受請求時，它看起來是有效的。 服務(wù)器應(yīng)該在實體的主體部分包含對請求狀態(tài)的描述，或許還應(yīng)該有對請求完成時間的估計（或者包含一個指針，只想可以獲取此信息的位置）。 |
| 203 | Non-Authoritative Infomation | 實體首部包含的信息不是來自源端服務(wù)器，而是來自資源的一份副本，如果中間節(jié)點上有一份資源副本，但無法或者沒有對它所發(fā)送的與資源有關(guān)的元信息(首部)進(jìn)行驗證，就會出現(xiàn)這種情況。這個狀態(tài)碼不是非用不可，如果實體首部來自源端服務(wù)器，響應(yīng)為200狀態(tài)的應(yīng)用程序就可以將其作為一種可選項使用。 |
| 204 | No Content | 響應(yīng)報文中包含若干首部和一個狀態(tài)行，但沒有實體的主體部分。主要用于在瀏覽器不轉(zhuǎn)為顯示新文檔的情況下，對其進(jìn)行更新(比如刷新一個表單頁面)。 |
| 205 | Reset Content | 另一個主要用于瀏覽器的狀態(tài)碼，負(fù)責(zé)告知瀏覽器清楚當(dāng)前頁面中的所有HTML表單元素。 |
| 206 | Partial Content | 成功執(zhí)行一個部分或 Range(范圍) 請求。206響應(yīng)中必須包含Content-Range、Date以及ETag或Content-Location首部。 |
300 ~ 399 重定向狀態(tài)碼
| 狀態(tài)碼 | 原因短語 | 含義 |
|---|---|---|
| 300 | Multiple Choices | 客戶端請求一個實際指向多個資源的 URL 時會返回這個狀態(tài)碼，比如服務(wù)器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶著一個選項列表；這樣用戶就可以選擇他希望使用的那一項了。有多個版本可用時，客戶端需要溝通解決。服務(wù)器可以在 Location 首部包含首選 URL。 |
| 301 | Moved Permanently | 在請求的 URL 已被移除時使用。響應(yīng)的 Location 首部中應(yīng)該包含資源現(xiàn)在所處的URL。 |
| 302 | Found | 與 301 狀態(tài)碼類似；但是，客戶端應(yīng)該使用 Location 首部給出的 URL 來臨時定位資源。將來的請求仍應(yīng)該使用老的URL。 |
| 303 | See Other | 告知客戶端應(yīng)該用另一個 URL 來獲取資源。新的 URL 位于響應(yīng)報文的 Location 首部。其主要目的是允許 POST 請求的響應(yīng)將客戶端定向到某個資源上去。 |
| 304 | Mot Modified | 客戶端可以通過所包含的請求首部，使其請求變成有條件的。如果客戶端發(fā)起一個條件 GET 請求，而最近資源未被修改的話，就可以用這個狀態(tài)碼來說明資源未被修改。帶有這個狀態(tài)碼的響應(yīng)不應(yīng)該包含實體的主體部分。 |
| 305 | Use Proxy | 用來說明必須通過一個代理來訪問資源；代理的位置由 Location 首部給出。很重要一點是，客戶端是相對某個特定資源來解析這條響應(yīng)的，不能假定所有請求，甚至所有對持有所請求資源的服務(wù)器的請求都通過這個代理進(jìn)行。如果客戶端錯誤地讓代理介入了某條請求，可能會引發(fā)破壞性行為，會造成安全漏洞。 |
| 306 | (未被使用) | 當(dāng)前未使用。 |
| 307 | Temporary Redirect | 與301狀態(tài)碼類似；但客戶端應(yīng)該使用 Location 首部給出的 URL 來臨時定位資源。將來的請求應(yīng)該使用老的 URL。 |
302，303，307之間存在交叉，主要來之于 HTTP/1.0 和 HTTP/1.1 的處理方式不同。
當(dāng) HTTP/1.0 客戶端發(fā)起一個 POST 請求，并在響應(yīng)中收到了 302 重定向狀態(tài)碼時，它會接受 Location 首部的重定向 URL，并向那個 URL 發(fā)起一個 GET 請求（而不會像原始請求中那樣發(fā)起一個 POST 請求）。
而在 HTTP/1.1 中，HTTP/1.1 規(guī)范使用 303 狀態(tài)碼來實現(xiàn)同樣的行為（服務(wù)器發(fā)送 303 狀態(tài)碼來重定向客戶端的 POST 請求，在它后面跟上一個 GET 請求）。
為了避開這個問題，HTTP/1.1 規(guī)范指出，對于 HTTP/1.1 客戶端，用 307 狀態(tài)碼取代302狀態(tài)碼來進(jìn)行重定向。這樣服務(wù)器就可以將 302 狀態(tài)碼保留起來，為HTTP／1.0 客戶端使用。
400 ~ 499 客戶端錯誤代碼
| 狀態(tài)碼 | 原因短語 | 含義 |
|---|---|---|
| 400 | Bad Request | 用于告知客戶端它發(fā)送了一個錯誤的請求 |
| 401 | Unauthorized | 與適當(dāng)?shù)氖撞恳煌祷兀谶@些首部中請求客戶端在獲取對資源的訪問權(quán)之前，對自己進(jìn)行認(rèn)證。 |
| 402 | Payment Required | 保留狀態(tài)碼 |
| 403 | Forbidden | 用于說明請求被服務(wù)器拒絕了。如果服務(wù)器想說明為什么拒絕請求，可以包含實體的主體部分來對原因進(jìn)行描述。但這個狀態(tài)碼通常是用在服務(wù)器不想說明拒絕原因的時候使用。 |
| 404 | Not Found | 用于說明服務(wù)器無法找到所請求 URL。通常會包含一個實體，以便客戶端應(yīng)用程序現(xiàn)實給用戶看。 |
| 405 | Method Not Allowed | 發(fā)起請求中帶有所請求的 URL 不支持的方法時，使用此狀態(tài)碼。應(yīng)該在響應(yīng)中包含 Allow 首部，以告知客戶端對所請求的資源可以使用哪些方法。 |
| 406 | Not Acceptable | 客戶端可以指定參數(shù)哦來說明它們愿意接收什么類型的實體。服務(wù)器沒有與客戶端可以接受的 URL 相匹配的資料時，使用此代碼。通常，服務(wù)器會包含一些首部，以便客戶端弄清楚為什么請求無法滿足。 |
| 407 | Proxy Authentication Required | 與 401 狀態(tài)碼類似，但用于要求對資源進(jìn)行認(rèn)證的代理服務(wù)器。 |
| 408 | Request Timeout | 如果客戶端完成請求所花的時間太長，服務(wù)器可能回送此狀態(tài)碼，并關(guān)閉連接。超時時長隨服務(wù)器的不同有所不同，但通常對所有的合法請求來說，都是夠長的。 |
| 409 | Conflict | 用于說明請求可能在資源上引發(fā)的一些沖突。服務(wù)器擔(dān)心請求會引發(fā)沖突時，可以發(fā)送此狀態(tài)碼。響應(yīng)中應(yīng)該包含描述沖突的主體。 |
| 410 | Gone | 與 404 類似，只是服務(wù)器曾經(jīng)擁有過此資源。主要用于 Web 站點的維護(hù)，這樣服務(wù)器的管理者就可以在資源被移除的情況下通知客戶端。 |
| 411 | Length Required | 服務(wù)器要求在請求報文中包含 Content-Length 首部使用。 |
| 412 | Precondition Failed | 客戶端發(fā)起了條件請求，且其中一個條件失敗了的時候使用。客戶端包含了 Expect 首部發(fā)起的就是條件請求。 |
| 413 | Request Entity Too Large | 客戶端發(fā)送的實體主體部分比服務(wù)器能夠或者希望處理的要大時，使用此狀態(tài)碼。 |
| 414 | Request URI Too Long | 客戶端發(fā)送請求中的請求 URL 比服務(wù)器能夠或者希望處理的要長時，使用此狀態(tài)碼。 |
| 415 | Unsupported Media Type | 服務(wù)器無法理解或者無法支持客戶端所發(fā)實體的內(nèi)容類型時，使用此狀態(tài)碼。 |
| 416 | Requested Range Not Satisfiable | 請求報文所請求的是指定資源的某個范圍，而此范圍無效或者無法滿足時，使用此狀態(tài)。 |
| 417 | Expectation Failed | 請求的 Expect 請求首部包含了一個期望，但服務(wù)器無法滿足此期望時，使用此代碼。如果代理或者其他中間應(yīng)用程序由確切證據(jù)說明源服務(wù)器會為某請求產(chǎn)生一個失敗的期望，就可以發(fā)送這個響應(yīng)狀態(tài)碼。 |
500 ~599 服務(wù)器錯誤狀態(tài)碼
| 狀態(tài)碼 | 原因短語 | 含義 |
|---|---|---|
| 500 | Internal Server Error | 服務(wù)器遇到一個妨礙它作為請求提供服務(wù)的錯誤時，使用此狀態(tài)。 |
| 501 | Not Implemented | 客戶端發(fā)起的請求超過服務(wù)器能力范圍（比如，使用了服務(wù)器不支持的請求方法）時，使用此狀態(tài)。 |
| 502 | Bad Gateway | 作為代理或網(wǎng)關(guān)使用的服務(wù)器從請求響應(yīng)鏈的下一條鏈路上收到了一條偽響應(yīng)（比如，他無法連接到父網(wǎng)關(guān)）時，使用此狀態(tài)。 |
| 503 | Service Unavailabe | 用來說明服務(wù)器現(xiàn)在無法為請求提供服務(wù)，但將來可以。如果服務(wù)器知道什么時候資源會變?yōu)榭捎玫模梢栽陧憫?yīng)中包含一個 Retry-After 首部。 |
| 504 | Gateway Timeout | 與狀態(tài)碼408類似，只是這里的響應(yīng)來自一個網(wǎng)關(guān)或代理，它們在等待里一服務(wù)器對其請求進(jìn)行響應(yīng)超時了。 |
| 505 | HTTP Version Not Supported | 服務(wù)器收到的請求使用了它無法或不愿支持的協(xié)議版本時，使用此狀態(tài)碼。有些服務(wù)器應(yīng)用程序會選擇不支持早期版本的協(xié)議。 |
首部
1.通用首部
有些首部時客戶端和服務(wù)端都能使用，且提供了與報文相關(guān)的最基本信息，叫做通用首部。
通用信息首部
| 首部 | 描述 |
|---|---|
| Connection | 允許客戶端和服務(wù)器指定與請求/響應(yīng)連接有關(guān)的選項。 |
| Date | 提供日期和時間標(biāo)志，說明報文是什么時間創(chuàng)建的。 |
| MIME-Version | 給出了發(fā)送短使用的 MINE 版本。 |
| Trailer | 如果報文采用了分塊傳輸編碼(chunked transfer encoding)方式，就可以用這個首部列出位于報文拖掛(trailer)部分的首部集合。 |
| Transfer-Encoding | 告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式。 |
| Update | 給出了發(fā)送端可能想要"升級"使用的新版本或協(xié)議。 |
| Via | 顯示報文經(jīng)過的中間節(jié)點（代理、網(wǎng)關(guān)）。 |
通用緩存首部
| 首部 | 描述 |
|---|---|
| Cache-Control | 用于隨報文傳送緩存指示。 |
| Pragma | 另一種隨報文傳送指示的方式，當(dāng)并不專用于緩存。 |
2.請求首部
請求首部是只在請求報文中有意義的首部。
請求的信息性首部
| 首部 | 描述 |
|---|---|
| Client-IP | 提供了運行客戶端的機(jī)器的IP地址。 |
| From | 提供了客戶端用戶的 Email 地址。（使用RFC 822 E-mail地址格式） |
| Host | 給出了接受請求的服務(wù)器的主機(jī)名和端口號。 |
| Referer | 提供了包含當(dāng)前請求 URI 的文檔的 URL。 |
| UA-Color | 提供了與客戶端顯示器的現(xiàn)實顏色有關(guān)的信息。 |
| UA-CPU | 提供了客戶端 CPU 的類型和制造商。 |
| UA-Disp | 提供了與客戶端顯示器能力有關(guān)的信息。 |
| UA-OS | 給出了運行在客戶端機(jī)器上的操作系統(tǒng)名稱和版本。 |
| UA-Pixels | 提供了客戶端顯示器的色素信息。 |
| User-Agent | 將發(fā)起請求的應(yīng)用程序名告知服務(wù)器。 |
Accept首部
Accept首部為客戶端提供了一種將其喜好和能力告知服務(wù)器的方式。Accept首部會使連接的兩端都受益。
| 首部 | 描述 |
|---|---|
| Accept | 告訴服務(wù)器能夠發(fā)送哪些媒體類型。 |
| Accept-Charset | 告訴服務(wù)器能夠發(fā)送哪些字符集。 |
| Accept-Encoding | 告訴服務(wù)器能夠發(fā)送哪些編碼方式。 |
| Accept-Language | 告訴服務(wù)器能夠發(fā)送哪些語言。 |
| TE | 告訴服務(wù)器可以使用哪些擴(kuò)咱傳輸編碼。 |
條件請求首部
有時客戶端希望為請求加上某些限制。比如，客戶端已經(jīng)有了一份文檔副本，就希望只在服務(wù)器上的文檔與客戶端擁有的副本有區(qū)別時，才請求服務(wù)器傳輸文檔。通過條件請求首部，客戶端就可以為請求加上這種限制，要求服務(wù)器在對請求進(jìn)行響應(yīng)之前，確保某個條件為真。
| 首部 | 描述 |
|---|---|
| Expect | 允許客戶端列出請求所要求的服務(wù)器行為。 |
| If-Match | 如果實體標(biāo)記與文檔當(dāng)前的實體標(biāo)記相匹配，就獲取這份文檔。 |
| If-Modified-Since | 除非在某個指定的日期之后資源被修改過，否則就限制這個請求。 |
| If-None-Match | 如果提供的實體標(biāo)記與當(dāng)前文檔的實體標(biāo)記不相符，就獲取文檔。 |
| If-Range | 允許對文檔的某個范圍進(jìn)行條件請求。 |
| If-Unmodified-Since | 除非在某個指定日期之后資源沒有被修改過，否則限制這個請求。 |
| Range | 如果服務(wù)器支持范圍請求，就請求資源的指定范圍。 |
安全請求首部
| 首部 | 描述 |
|---|---|
| Authorization | 包含了提供給服務(wù)器來對客戶端進(jìn)行自身認(rèn)證的數(shù)據(jù)。 |
| Cookie | 客戶端用它向服務(wù)器傳送一個令牌-----它并不是真正的安全首部，但卻是隱含了安全功能。 |
| Cookie2 | 用來說明請求端支持的cookie版本。 |
代理請求首部
| 首部 | 描述 |
|---|---|
| Max-Forward | 在通往源端服務(wù)器的路徑上，將請求轉(zhuǎn)發(fā)給其他代理或網(wǎng)管的最大次數(shù)----與 TRACE 方法一同使用。 |
| Proxy-Authorization | 與 Authorization 首部相同，但這個首部是在于代理進(jìn)行認(rèn)證時使用的。 |
| Proxy-Connection | 與 Connection 首部相同，但這個首部是在于代理建立連接時使用的。 |
3.響應(yīng)首部
響應(yīng)的信息性首部
| 首部 | 描述 |
|---|---|
| Age | （從最初創(chuàng)建開始)響應(yīng)持續(xù)時間。 |
| Public | 服務(wù)器為其資源支持的請求方法列表。 |
| Retry-After | 如果資源不可用的話，在此日期或時間重試。 |
| Server | 服務(wù)器應(yīng)用程序軟件的名稱和版本。 |
| Title | 對 HTML 文檔來說，就是 HTML 文檔的源端給出的標(biāo)題。 |
| Warning | 比原因短語更詳細(xì)一些的警告報文。 |
協(xié)商首部
| 首部 | 描述 |
|---|---|
| Accept-Ranges | 對此資源來說，服務(wù)器可接受的范圍類型。 |
| Vary | 服務(wù)器查看的其他首部列表，可能會使響應(yīng)發(fā)生變化；也就是說，這是一個首部列表，服務(wù)器會根據(jù)這些首部的內(nèi)容挑選出最適合的資源版本發(fā)送給客戶端。 |
安全響應(yīng)首部
| 首部 | 描述 |
|---|---|
| Proxy-Authenticate | 來自代理的對客戶端的質(zhì)詢列表。 |
| Set-Cookie | 不是真正的安全首部，但隱含安全功能；可以在客戶端設(shè)置一個令牌，以便服務(wù)器對其客戶端進(jìn)行標(biāo)識。 |
| Set-Cookie2 | 與 Set-Cookie 類似，PFC 2965 Cookie定義。 |
| WWW-Authenticate | 來自服務(wù)器對客戶端的質(zhì)詢列表。 |
4.實體首部
實體首部提供了有關(guān)實體及其內(nèi)容的大量信息，請求和響應(yīng)報文中都可能包含實體部分，所以這兩類報文都可能出現(xiàn)這些首部。總之，實體首部可以告知報文的接收者它在對什么進(jìn)行處理。
實體的信息性首部
| 首部 | 描述 |
|---|---|
| Allow | 列出可以對此事提執(zhí)行的請求方法。 |
| Location | 告知客戶端實際上位于何處；用于將接收端定向到資源的(可能是新的)位置(URL)上去。 |
內(nèi)容首部
內(nèi)容首部提供了與實體內(nèi)容有關(guān)的特定信息，說明了其類型，尺寸以及處理它所需要的其它有用信息。
| 首部 | 描述 |
|---|---|
| Content-Base | 解釋主體中的相對 URL 時使用的基礎(chǔ) URL |
| Content-Encoding | 對主體執(zhí)行的任意編碼方式。 |
| Content-Language | 理解主體時最適宜使用的自然語言。 |
| Content-Length | 主體的長度或尺寸。 |
| Content-Locaton | 資源實際所處的位置。 |
| Content-MD5 | 主體的 MD5 校驗和。 |
| Content-Range | 在整個資源中此實體表示的字節(jié)范圍。 |
| Content-Type | 在這個主體的對象類型。 |
實體緩存首部
通用的緩存首部說明了如何或者什么時候進(jìn)行緩存。實體的緩存首部提供了與被緩存實體有關(guān)的信息。
| 首部 | 描述 |
|---|---|
| ETag | 與此實體相關(guān)的實體標(biāo)記。 |
| Expires | 實體不再有效，要從原始的源端再次獲取此實體的日期和時間。 |
| Last-Modified | 這個實體最后一次被修改的日期和時間。 |
