更詳細的介紹：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status
HTTP（HyperTextTransferProtocol）即超文字傳輸協定，目前網頁傳輸的的通用協定。HTTP協定採用了請求/響應模型，瀏覽器或其他用戶端發出請求，伺服器給與響應。就整個網路資源傳輸而言，包括message-header和message-body兩部分。http header 訊息通常被分爲4個部分：general header, request header, response header, entity header。但是這種分法就理解而言，感覺界限不太明確。根據維基百科對http header內容的組織形式，大體分爲Request和Response兩部分。
| Header | 解釋 | 範例 |
|---|---|---|
| Accept | 指定用戶端能夠接收的內容型別 | Accept: text/plain, text/html |
| Accept-Charset | 瀏覽器可以接受的字元編碼集 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定瀏覽器可以支援的web伺服器返回內容壓縮編碼型別 | Accept-Encoding: compress, gzip |
| Accept-Language | 瀏覽器可接受的語言 | Accept-Language: en,zh |
| Accept-Ranges | 可以請求網頁實體的一個或者多個子範圍欄位 | Accept-Ranges: bytes |
| Authorization | HTTP授權的授權證書 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定請求和響應遵循的快取機制 機製 | Cache-Control: no-cache |
| Connection | 表示是否需要持久連線。（HTTP 1.1預設進行持久連線） | Connection: close |
| Cookie | HTTP請求發送時，會把儲存在該請求域名下的所有cookie值一起發送給web伺服器 | Cookie: $Version=1; Skin=new; |
| Content-Length | 請求的內容長度 | Content-Length: 348 |
| Content-Type | 請求的與實體對應的MIME資訊 | Content-Type: application/x-www-form-urlencoded |
| Date | 請求發送的日期和時間 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 請求的特定的伺服器行爲 | Expect: 100-continue |
| From | 發出請求的使用者的Email | From: [email protected] |
| Host | 指定請求的伺服器的域名和埠號 | Host: www.zcmhi.com |
| If-Match | 只有請求內容與實體相匹配纔有效 | If-Match: 「737060cd8c284d8af7ad3082f209582d」 |
| If-Modified-Since | 如果請求的部分在指定時間之後被修改則請求成功，未被修改則返回304程式碼 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果內容未改變返回304程式碼，參數爲伺服器先前發送的Etag，與伺服器迴應的Etag比較判斷是否改變 | If-None-Match: 「737060cd8c284d8af7ad3082f209582d」 |
| If-Range | 如果實體未改變，伺服器發送用戶端丟失的部分，否則發送整個實體。參數也爲Etag | If-Range: 「737060cd8c284d8af7ad3082f209582d」 |
| If-Unmodified-Since | 只在實體在指定時間之後未被修改才請求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制資訊通過代理和閘道器傳送的時間 | Max-Forwards: 10 |
| Pragma | 用來包含實現特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 連線到代理的授權證書 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只請求實體的一部分，指定範圍 | Range: bytes=500-999 |
| Referer | 先前網頁的地址，當前請求網頁緊隨其後,即來路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 用戶端願意接受的傳輸編碼，並通知伺服器接受接受尾加頭資訊 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向伺服器指定某種傳輸協定以便伺服器進行轉換（如果支援） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的內容包含發出請求的使用者資訊 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中間閘道器或代理伺服器地址，通訊協定 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 關於訊息實體的警告資訊 | Warn: 199 Miscellaneous warning |
| Header | 解釋 | 範例 |
|---|---|---|
| Accept-Ranges | 表明伺服器是否支援指定範圍請求及哪種型別的分段請求 | Accept-Ranges: bytes |
| Age | 從原始伺服器到代理快取形成的估算時間（以秒計，非負） | Age: 12 |
| Allow | 對某網路資源的有效的請求行爲，不允許則返回405 | Allow: GET, HEAD |
| Cache-Control | 告訴所有的快取機制 機製是否可以快取及哪種型別 | Cache-Control: no-cache |
| Content-Encoding | web伺服器支援的返回內容壓縮編碼型別。 | Content-Encoding: gzip |
| Content-Language | 響應體的語言 | Content-Language: en,zh |
| Content-Length | 響應體的長度 | Content-Length: 348 |
| Content-Location | 請求資源可替代的備用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回資源的MD5校驗值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整個返回體中本部分的位元組位置 | |
| Content-Type | 返回內容的MIME型別 | Content-Type: text/html; charset=utf-8 |
| Date | 原始伺服器訊息發出的時間 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 請求變數的實體標籤的當前值 | ETag: 「737060cd8c284d8af7ad3082f209582d」 |
| Expires | 響應過期的日期和時間 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 請求資源的最後修改時間 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括實現特定的指令，它可應用到響應鏈上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出認證方案和可應用到代理的該URL上的參數 | Proxy-Authenticate: Basic |
| refresh | 應用於重定向或一個新的資源被創造，在5秒之後重定向（由網景提出，被大部分瀏覽器支援） | Refresh: 5; url=http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果實體暫時不可取，通知用戶端在指定時間之後再次嘗試 | Retry-After: 120 |
| Server | web伺服器軟體名稱 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 設定Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出頭域在分塊傳輸編碼的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 檔案傳輸編碼 | Transfer-Encoding:chunked |
| Vary | 告訴下遊代理是使用快取響應還是從原始伺服器請求 | Vary: * |
| Via | 告知代理用戶端響應是通過哪裏發送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告實體可能存在的問題 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明用戶端請求實體應該使用的授權方案 | WWW-Authenticate: Basic |
HTTP方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。
HTTP GET方法用於獲取資源，不應有副作用，所以是冪等的。 比如：GET http://www.bank.com/account/123456，不會改變資源的狀態，不論呼叫一次還是N次都沒有副作用。請注意，這裏強調的是一次和N次具有相同的副作用，而不是每次GET的結果相同。GET http://www.news.com/latest-news這個HTTP請求可能會每次得到不同的結果，但它本身並沒有產生任何副作用，因而是滿足冪等性的。
HTTP DELETE方法用於刪除資源，有副作用，但它應該滿足冪等性。 比如：DELETE http://www.forum.com/article/4231，呼叫一次和N次對系統產生的副作用是相同的，即刪掉id爲4231的貼文；因此，呼叫者可以多次呼叫或重新整理頁面而不必擔心引起錯誤。
比較容易混淆的是HTTP POST和PUT。POST和PUT的區別容易被簡單地誤認爲「POST表示建立資源，PUT表示更新資源」；而實際上，二者均可用於建立資源，更爲本質的差別是在冪等性方面。在HTTP規範中對POST和PUT是這樣定義的：
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line … If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
POST所對應的URI並非建立的資源本身，而是資源的接收者。比如：POST http://www.forum.com/articles的語意是在http://www.forum.com/articles下建立一篇貼文，HTTP響應中應包含貼文的建立狀態以及貼文的URI。兩次相同的POST請求會在伺服器端建立兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。
PUT所對應的URI是要建立或更新的資源本身。比如：PUT http://www.forum/articles/4231的語意是建立或更新ID爲4231的貼文。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
摘自：https://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html