司空見慣的Http，訪問網頁，請求接口，可謂無處不在，那麼什麼是Http呢？這篇文章，會給大家做一個簡單的總結，雖然說，在開發中我們即便不去了解，也不會影響到我們，但對於常見的面試環節，這個不得不顯得尤爲重要，知之總比不知強。
什麼是Http?
說白了，它是一個標準，比如你去做火車，需要憑藉火車票或有效證件才能去乘坐，那麼這就是標準，標準，是人制定的，需要按照它去執行的，要不然沒有這個標準，一個人有一個人的想法，這樣將會非常的混亂，同樣，我們的Http，它也是一個標準，一個協議，是因特網上應用最爲廣泛的一種網絡傳輸協議，所有的WWW文件都必須遵守這個標準。英文全稱，HyperText Transfer Protocol，翻譯爲：超文本傳輸協議，這個需要簡單的瞭解一下。
HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議工作於客戶端-服務端架構爲上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。
Http1.0和Http1.1:
HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始廣泛應用於現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲廣泛的HTTP協議。 主要區別主要體現在：
緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
帶寬優化及網絡連接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。
Http的主要特點：
1、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
2、靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
3.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
5、支持B/S及C/S模式。
B/S及C/S模式【擴展】
C/S模式：
C/S(Client/Server,客戶/服務器)方式的網絡計算模式，A、服務器負責管理數據庫的訪問，並對客戶機/服務器網絡結構中的數據庫安全層加鎖，進行保護；B、客戶機負責與用戶的交互，收集用戶信息，通過網絡向服務器發送請求。C、C/S模式中，資源明顯不對等，是一種“胖客戶機(fat client)”或“瘦服務器(thin server)”結構。D、客戶程序（前臺程序）在客戶機上運行，數據庫服務程序（後臺程序）在應用服務器上運行。
B/S模式：
B/S(Browser/Server,瀏覽器/服務器)方式的網絡結構，A、客戶端統一採用瀏覽器如：Netscape和IE，通過Web瀏覽器向Web服務器提出請求，由Web服務器對數據庫進行操作，並將結果傳回客戶端。B、B/S結構簡化了客戶機的工作，但服務器將擔負更多的工作，對數據庫的訪問和應用程序的執行都將在這裏完成。即當瀏覽器發出請求後，其數據請求、加工、返回結果、動態網頁生成等工作全部由Web服務器完成。
Http之URL
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。
http://www.vipandroid.cn/cert/get_news_speak.php?open_id=100#name
從上面的URL可以看出，一個完整的URL包括以下幾部分：
1.協議部分：該URL的協議部分爲“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的“//”爲分隔符
2.域名部分：該URL的域名部分爲“www.vipandroid.cn”。一個URL中，也可以使用IP地址作爲域名使用
3.端口部分：跟在域名後面的是端口，域名和端口之間使用“:”作爲分隔符。端口不是一個URL必須的部分，如果省略端口部分，將採用默認端口
4.虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/cert/”
5.文件名部分：從域名後的最後一個“/”開始到“？”爲止，是文件名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”爲止，是文件部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是文件名部分。本例中的文件名是“get_news_speak.php”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名
6.錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
7.參數部分：從“？”開始到“#”爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲“open_id=100”。參數可以允許有多個參數，參數與參數之間用“&”作爲分隔符。
URI與URL區別
很多人會混淆這兩個名詞。
URL：(Uniform/Universal Resource Locator 的縮寫，統一資源定位符)。
URI：(Uniform Resource Identifier 的縮寫，統一資源標識符)（代表一種標準）。
關係：
URI 屬於 URL 更高層次的抽象，一種字符串文本標準。
就是說，URI 屬於父類，而 URL 屬於 URI 的子類。URL 是 URI 的一個子集。
二者的區別在於，URI 表示請求服務器的路徑，定義這麼一個資源。而 URL 同時說明要如何訪問這個資源（http://）。
URI實例：
大家把瀏覽器地址欄裏訪問網站的地址認爲是URL就好了，也就是以HTTP/HTTPS開頭的URI子集。
端口與URL標準格式
何爲端口？端口(Port)，相當於一種數據的傳輸通道。用於接受某些數據，然後傳輸給相應的服務，而電腦將這些數據處理後，再將相應的回覆通過開啓的端口傳給對方。
端口的作用：因爲 IP 地址與網絡服務的關係是一對多的關係。所以實際上因特網上是通過 IP 地址加上端口號來區分不同的服務的。
端口是通過端口號來標記的，端口號只有整數，範圍是從0 到65535。
URL標準格式
通常而言，我們所熟悉的 URL 的常見定義格式爲：
scheme://host[:port#]/path/.../[;url-params][?query-string][#anchor]
scheme //有我們很熟悉的http、https、ftp以及著名的ed2k，迅雷的thunder等。
host //HTTP服務器的IP地址或者域名
port# //HTTP服務器的默認端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如tomcat的默認端口是8080 http://localhost:8080/
path //訪問資源的路徑
url-params //所帶參數
query-string //發送給http服務器的數據
anchor //錨點定位
URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:[email protected]。
URI與URL的區別【總結】
URI(uniform resource identifier)，意思是統一資源標識符，用於唯一的標識一個資源。
Web上可用的每種資源如HTML文檔、圖像、視頻等都是用URI來定位的。
一個URI由三部分組成：
訪問資源的命名機制
存放資源的主機名
資源自身名稱，由路徑表示
URL(uniform resource locator)，意思是統一資源定位器，它是一種具體的URI。可以用來標識一個資源，而且還指明瞭如何鎖定這個資源。
URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上。採用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄 。
一個URL由三部分組成：
協議
存有資源的主機IP地址(包含端口號)
主機資源具體地址
請求方法
根據HTTP標準，HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
常見狀態碼
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文爲HTTP Status Code。
下面是常見的HTTP狀態碼：
200 - 請求成功
301 - 資源（網頁等）被永久轉移到其它URL
404 - 請求的資源（網頁等）不存在
500 - 內部服務器錯誤
HTTP之請求消息Request
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：
請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。
請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。
Get請求例子，使用Charles抓取的request：
第一部分：請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
GET說明請求類型爲
|
GET /cert/get_news_speak.php?open_id=100 HTTP/1.1 |
爲要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。
第二部分：請求頭部，緊接着請求行（即第一行）之後的部分，用來說明服務器要使用的附加信息
從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,並且在每個請求中自動發送等等
第三部分：空行，請求頭部後面的空行是必須的
即使第四部分的請求數據爲空，也必須有空行。
第四部分：請求數據也叫主體，可以添加任意的其他數據。
這個例子的請求數據爲空。
POST請求例子，使用Charles抓取的request：
第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求數據，第八行。
HTTP之響應消息Response
一般情況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。
第一行爲狀態行，（HTTP/1.1）表明HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）
第二部分：消息報頭，用來說明客戶端要使用的一些附加信息
第二行和第三行爲消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的application/json,編碼類型是UTF-8
第三部分：空行，消息報頭後面的空行是必須的
第四部分：響應正文，服務器返回給客戶端的文本信息。
空行後面的html部分爲響應正文。
GET和POST的區別
GET提交的數據會放在URL之後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.
GET提交的數據大小有限制（因爲瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼.
HTTP工作原理
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。
以下是 HTTP 請求/響應的步驟：
1、客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認爲80）建立一個TCP套接字連接。例如，http://www.oakcms.cn。
2、發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
3、服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4、釋放連接TCP連接
若connection 模式爲close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式爲keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;
5、客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看錶明請求是否成功的狀態代碼。然後解析每一個響應頭，響應頭告知以下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。
例如：在瀏覽器地址欄鍵入URL，按下回車之後會經歷以下流程：
1、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
2、解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器建立TCP連接;
3、瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文作爲 TCP 三次握手的第三個報文的數據發送給服務器;
4、服務器對瀏覽器請求作出響應，並把對應的 html 文本發送給瀏覽器;
5、釋放 TCP連接;
6、瀏覽器將該 html 文本並顯示內容;
【補充】
常用的HTTP請求頭
|
協議頭 |
說明 |
示例 |
狀態 |
|
Accept |
可接受的響應內容類型（ |
|
固定 |
|
Accept-Charset |
可接受的字符集 |
|
固定 |
|
Accept-Encoding |
可接受的響應內容的編碼方式。 |
|
固定 |
|
Accept-Language |
可接受的響應內容語言列表。 |
|
固定 |
|
Accept-Datetime |
可接受的按照時間來表示的響應內容版本 |
Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT |
臨時 |
|
Authorization |
用於表示HTTP協議中需要認證資源的認證信息 |
Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE== |
固定 |
|
Cache-Control |
用來指定當前的請求/回覆中的，是否使用緩存機制。 |
|
固定 |
|
Connection |
客戶端（瀏覽器）想要優先使用的連接類型 |
|
固定 |
|
Cookie |
由之前服務器通過 |
|
固定：標準 |
|
Content-Length |
以8進製表示的請求體的長度 |
|
固定 |
|
Content-MD5 |
請求體的內容的二進制 MD5 散列值（數字簽名），以 Base64 編碼的結果 |
Content-MD5: oD8dH2sgSW50ZWdyaIEd9D== |
廢棄 |
|
Content-Type |
請求體的MIME類型 （用於POST和PUT請求中） |
Content-Type: application/x-www-form-urlencoded |
固定 |
|
Date |
發送該消息的日期和時間（以RFC 7231中定義的"HTTP日期"格式來發送） |
Date: Dec, 26 Dec 2015 17:30:00 GMT |
固定 |
|
Expect |
表示客戶端要求服務器做出特定的行爲 |
|
固定 |
|
From |
發起此請求的用戶的郵件地址 |
|
固定 |
|
Host |
表示服務器的域名以及服務器所監聽的端口號。如果所請求的端口是對應的服務的標準端口（80），則端口號可以省略。 |
|
固定 |
|
If-Match |
僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操作。主要用於像 PUT 這樣的方法中，僅當從用戶上次更新某個資源後，該資源未被修改的情況下，才更新該資源。 |
If-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" |
固定 |
|
If-Modified-Since |
允許在對應的資源未被修改的情況下返回304未修改 |
If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT |
固定 |
|
If-None-Match |
允許在對應的內容未被修改的情況下返回304未修改（ 304 Not Modified ），參考 超文本傳輸協議 的實體標記 |
If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" |
固定 |
|
If-Range |
如果該實體未被修改過，則向返回所缺少的那一個或多個部分。否則，返回整個新的實體 |
If-Range: "9jd00cdj34pss9ejqiw39d82f20d0ikd" |
固定 |
|
If-Unmodified-Since |
僅當該實體自某個特定時間以來未被修改的情況下，才發送迴應。 |
If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT |
固定 |
|
Max-Forwards |
限制該消息可被代理及網關轉發的次數。 |
|
固定 |
|
Origin |
發起一個針對跨域資源共享的請求（該請求要求服務器在響應中加入一個 |
|
固定: 標準 |
|
Pragma |
與具體的實現相關，這些字段可能在請求/迴應鏈中的任何時候產生。 |
|
固定 |
|
Proxy-Authorization |
用於向代理進行認證的認證信息。 |
Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2== |
固定 |
|
Range |
表示請求某個實體的一部分，字節偏移以0開始。 |
|
固定 |
|
Referer |
表示瀏覽器所訪問的前一個頁面，可以認爲是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面。 |
Referer: http://itbilu.com/nodejs |
固定 |
|
TE |
瀏覽器預期接受的傳輸時的編碼方式：可使用迴應協議頭 |
|
固定 |
|
User-Agent |
瀏覽器的身份標識字符串 |
|
固定 |
|
Upgrade |
要求服務器升級到一個高版本協議。 |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
固定 |
|
Via |
告訴服務器，這個請求是由哪些代理髮出的。 |
Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1) |
固定 |
|
Warning |
一個一般性的警告，表示在實體內容體中可能存在錯誤。 |
Warning: 199 Miscellaneous warning |
固定 |
常用的HTTP響應頭
|
響應頭 |
說明 |
示例 |
狀態 |
|
Access-Control-Allow-Origin |
指定哪些網站可以 |
|
臨時 |
|
Accept-Patch |
指定服務器所支持的文檔補丁格式 |
Accept-Patch: text/example;charset=utf-8 |
固定 |
|
Accept-Ranges |
服務器所支持的內容範圍 |
|
固定 |
|
Age |
響應對象在代理緩存中存在的時間，以秒爲單位 |
|
固定 |
|
Allow |
對於特定資源的有效動作; |
|
固定 |
|
Cache-Control |
通知從服務器到客戶端內的所有緩存機制，表示它們是否可以緩存這個對象及緩存有效時間。其單位爲秒 |
|
固定 |
|
Connection |
針對該連接所預期的選項 |
|
固定 |
|
Content-Disposition |
對已知MIME類型資源的描述，瀏覽器可以根據這個響應頭決定是對返回資源的動作，如：將其下載或是打開。 |
Content-Disposition: attachment; filename="fname.ext" |
固定 |
|
Content-Encoding |
響應資源所使用的編碼類型。 |
|
固定 |
|
Content-Language |
響就內容所使用的語言 |
|
固定 |
|
Content-Length |
響應消息體的長度，用8進制字節表示 |
|
固定 |
|
Content-Location |
所返回的數據的一個候選位置 |
|
固定 |
|
Content-MD5 |
響應內容的二進制 MD5 散列值，以 Base64 方式編碼 |
Content-MD5: IDK0iSsgSW50ZWd0DiJUi== |
已淘汰 |
|
Content-Range |
如果是響應部分消息，表示屬於完整消息的哪個部分 |
Content-Range: bytes 21010-47021/47022 |
固定 |
|
Content-Type |
當前內容的 |
Content-Type: text/html; charset=utf-8 |
固定 |
|
Date |
此條消息被髮送時的日期和時間(以RFC 7231中定義的"HTTP日期"格式來表示) |
Date: Tue, 15 Nov 1994 08:12:31 GMT |
固定 |
|
ETag |
對於某個資源的某個特定版本的一個標識符，通常是一個 消息散列 |
ETag: "737060cd8c284d8af7ad3082f209582d" |
固定 |
|
Expires |
指定一個日期/時間，超過該時間則認爲此迴應已經過期 |
Expires: Thu, 01 Dec 1994 16:00:00 GMT |
固定: 標準 |
|
Last-Modified |
所請求的對象的最後修改日期(按照 RFC 7231 中定義的“超文本傳輸協議日期”格式來表示) |
Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT |
固定 |
|
Link |
用來表示與另一個資源之間的類型關係，此類型關係是在RFC 5988中定義 |
|
固定 |
|
Location |
用於在進行重定向，或在創建了某個新資源時使用。 |
Location: http://www.itbilu.com/nodejs |
固定 |
|
P3P |
P3P策略相關設置 |
P3P: CP="This is not a P3P policy! |
固定 |
|
Pragma |
與具體的實現相關，這些響應頭可能在請求/迴應鏈中的不同時候產生不同的效果 |
|
固定 |
|
Proxy-Authenticate |
要求在訪問代理時提供身份認證信息。 |
|
固定 |
|
Public-Key-Pins |
用於防止中間攻擊，聲明網站認證中傳輸層安全協議的證書散列值 |
Public-Key-Pins: max-age=2592000; pin-sha256="……"; |
固定 |
|
Refresh |
用於重定向，或者當一個新的資源被創建時。默認會在5秒後刷新重定向。 |
Refresh: 5; url=http://itbilu.com |
|
|
Retry-After |
如果某個實體臨時不可用，那麼此協議頭用於告知客戶端稍後重試。其值可以是一個特定的時間段(以秒爲單位)或一個超文本傳輸協議日期。 |
|
固定 |
|
Server |
服務器的名稱 |
|
固定 |
|
Set-Cookie |
設置 |
Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 |
固定: 標準 |
|
Status |
通用網關接口的響應頭字段，用來說明當前HTTP連接的響應狀態。 |
|
|
|
Trailer |
|
|
固定 |
|
Transfer-Encoding |
用表示實體傳輸給用戶的編碼形式。包括： |
Transfer-Encoding: chunked |
固定 |
|
Upgrade |
要求客戶端升級到另一個高版本協議。 |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
固定 |
|
Vary |
告知下游的代理服務器，應當如何對以後的請求協議頭進行匹配，以決定是否可使用已緩存的響應內容而不是重新從原服務器請求新的內容。 |
|
固定 |
|
Via |
告知代理服務器的客戶端，當前響應是通過什麼途徑發送的。 |
Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3) |
固定 |
|
Warning |
一般性警告，告知在實體內容體中可能存在錯誤。 |
Warning: 199 Miscellaneous warning |
固定 |
|
WWW-Authenticate |
表示在請求獲取這個實體時應當使用的認證模式。 |
|
固定 |