HTTP請求方法

根據HTTP標準，HTTP請求可以使用多種請求方法。 HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

請求頭示例：

Host: beacon.tingyun.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 

Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://blog.csdn.net
Cookie: Hm_lvt_93
Connection: keep-alive
Content-Length: 0

Accept

  請求頭用來告知客戶端可以處理的內容型別，這種內容型別用MIME型別來表示。藉助內容協商機制, 伺服器可以從諸多備選項中選擇一項進行應用，並使用 Content-Type 應答頭通知客戶端它的選擇。瀏覽器會基於請求的上下文來為這個請求頭設定合適的值，比如獲取一個CSS層疊樣式表時值與獲取圖片、視訊或指令碼檔案時的值是不同的。
 

語法：

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

Accept-Encoding

HTTP 請求頭 Accept-Encoding 會將客戶端能夠理解的內容編碼方式——通常是某種壓縮演算法——進行通知。通過內容協商的方式，服務端會選擇一個客戶端提議的方式，使用並在響應報文首部 Content-Encoding 中通知客戶端該選擇。
即使客戶端和伺服器都支援相同的壓縮演算法，在 identity 指令可以被接受的情況下，伺服器也可以選擇對響應主體不進行壓縮。導致這種情況出現的兩種常見的情形是：
  要傳送的資料已經經過壓縮，再次進行壓縮不會導致被傳輸的資料量更小。一些影象格式的檔案會存在這種情況；
  伺服器超載，無法承受壓縮需求導致的計算開銷。通常，如果伺服器使用超過80%的計算能力，微軟建議不要壓縮。
 

語法：

`Accept-Encoding: gzip
 Accept-Encoding: compress
 Accept-Encoding: deflate
 Accept-Encoding: br
 Accept-Encoding: identity
 Accept-Encoding: *

 // Multiple algorithms, weighted with the quality value syntax:
 Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

指令：

gzip
    表示採用 Lempel-Ziv coding (LZ77) 壓縮演算法，以及32位CRC校驗的編碼方式。
compress
    採用 Lempel-Ziv-Welch (LZW) 壓縮演算法。
deflate
    採用 zlib 結構和 deflate 壓縮演算法。
br
    表示採用 Brotli 演算法的編碼方式。
identity
    用於指代自身（例如：未經過壓縮和修改）。除非特別指明，這個標記始終可以被接受。
*
    匹配其他任意未在該首部欄位中列出的編碼方式。假如該首部欄位不存在的話，這個值是預設值。它並不代表任意演算法都支援，而僅僅表示演算法之間無優先次序。
;q= (qvalues weighting)
    值代表優先順序，用相對質量價值 表示，又稱為權重。 

Accept-Language

請求頭允許客戶端宣告它可以理解的自然語言，以及優先選擇的區域方言。藉助內容協商機制，伺服器可以從諸多備選項中選擇一項進行應用， 並使用Content-Language 應答頭通知客戶端它的選擇。瀏覽器會基於其使用者介面語言來為這個請求頭設定合適的值，即便是使用者可以進行修改，但是這種情況極少發生 (and is frown upon as it leads to fingerprinting)。
 當伺服器無法通過其他方式來確定應當使用的語言時——例如某一特定的URL，這是使用者明確指定的——這個請求頭可以用作提示。建議伺服器端永遠不要覆蓋明確指定的資訊。 Accept-Language訊息頭的內容通常不在使用者的掌控之中（例如在國外旅行時到提供網路服務的場所上網）；另外使用者可能會想要瀏覽非本地使用者介面語言的頁面。

Connection

 connection頭（header） 決定當前的事務完成後，是否會關閉網路連線。如果該值是“keep-alive”，網路連線就是持久的，不會關閉，使得對同一個伺服器的請求可以繼續在該連線上完成。
 除去標準的逐段傳輸（hop-by-hop）頭（Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization and Proxy-Authenticate），任何逐段傳輸頭都需要在 Connection 頭中列出，這樣才能讓第一個代理知道必須處理它們且不轉發這些頭。標準的逐段傳輸頭也可以列出（常見的例子是 Keep-Alive，但這不是必須的）。      

Content-Length

 一個實體訊息首部，用來指明發送給接收方的訊息主體的大小，即用十進位制數字表示的八位元組的數目。

Host

 Host請求頭指明瞭伺服器的域名（對於虛擬主機來說），以及（可選的）伺服器監聽的TCP埠號。如果沒有給定埠號，會自動使用被請求服務的預設埠（比如請求一個HTTP的URL會自動使用80埠）。
 HTTP/1.1 的所有請求報文中必須包含一個Host頭欄位。如果一個 HTTP/1.1 請求缺少 Host 頭欄位或者設定了超過一個的 Host 頭欄位，一個400（Bad Request）狀態碼會被返回。

Referer

 Referer首部包含了當前請求頁面的來源頁面的地址，即表示當前頁面是通過此來源頁面裡的連結進入的。服務端一般使用 Referer 首部識別訪問來源，可能會以此進行統計分析、日誌記錄以及快取優化等。

User-Agent

 User-Agent 首部包含了一個特徵字串，用來讓網路協議的對端來識別發起請求的使用者代理軟體的應用型別、作業系統、軟體開發商以及版本號。

語法：

User-Agent: <product> / <product-version> <comment>

Common format for web browsers:

User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>

響應頭示例：

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 25 Jun 2018 23:35:32 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: accept, content-type, classname
Access-Control-Allow-Methods: POST, GET, OPTIONS
Content-Encoding: gzip

HTTP響應也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文。
HTTP/1.1 :HTTP版本號
200 OK：HTTP狀態碼
從Server到Content-Encoding屬於訊息報頭

HTTP狀態碼分類

Content-Type

  Content-Type實體頭用於向接收方指示實體的介質型別，指定HEAD方法送到接收方的實體介質型別，或GET方法傳送的請求介質型別 Content-Range實體頭 
  Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在伺服器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth 

Content-Type 主要型別：

    text/plain
    text/html
    text/css
    image/jpeg
    image/png
    image/svg+xml
    audio/mp4
    video/mp4
    application/javascript
    application/pdf
    application/zip
    application/atom+xml