本文摘自《HTTP權威指南》

看完這篇文章你會理解以下概念：

• 報文是如何流動的
• HTTP報文的三個組成部分（起始行、首部和實體的主體部分）蜡峰；
• 請求和響應報文之間的區(qū)別畴蹭；
• 請求報文支持的各種功能（語法）氓仲；
• 和響應報文一起返回的各種狀態(tài)碼水慨；
• 各種各樣的HTTP首部都是用來做什么的；

報文流

HTTP報文是在HTTP應用程序之間發(fā)送的數(shù)據(jù)塊敬扛。這些數(shù)據(jù)塊以一些文本形式的元信息（meta-information）開頭晰洒，這些信息描述了報文的內(nèi)容及含義，后面跟著可選的數(shù)據(jù)部分舔哪。這些報文在客戶端欢顷、服務器和代理之間流動。術語“流入”捉蚤、“流出”、“上游”炼七、及“下游”都是用來描述報文方向的缆巧。

報文流入源端服務器

HTTP使用術語流入（inbound）和流出（outbound）來描述事務處理（transaction）的方向。報文流入源端服務器豌拙，工作完成之后陕悬，會流回用戶的Agent代理中。

報文向下游流動

HTTP報文會想河水一樣流動按傅。不管是請求報文還是響應報文捉超，所有報文都會向下游（downstream）流動。所有報文的發(fā)送者都在接收者的上游（upstream）唯绍。

注：上游拼岳、下游的概念是相對的。

報文的組成部分

HTTP報文是簡單的格式化數(shù)據(jù)塊况芒。它們由三個部分組成：對報文進行描述的起始行（start line）惜纸、包含屬性的首部（header）塊，以及可選的绝骚、包含數(shù)據(jù)的主體（body）部分耐版。

報文的語法

所有HTTP報文可分為兩類：請求報文（request message）和響應報文（response message）。請求報文會向服務器請求一個動作压汪。響應報文會將請求的結果返回給客戶端粪牲。兩者基本結構相同。

這是請求報文的格式：

<method> <request-URL> <version>
<header>
<entity-body>

這是響應報文的格式（注意：只有起始行的語法有所不同）：

<version> <status> <reason-phrase>
<header>
<entity-body>

start line（起始行）

所有的HTTP報文都以一個起始行作為開始止剖。請求報文的起始行說明了要做些什么腺阳。響應報文的起始行說明發(fā)生了什么落君。

• 請求行
  請求報文請求服務器對資源進行一些操作。請求報文的起始行舌狗，或成為請求行叽奥，包含了一個方法和一個請求URL，這個方法描述了服務器應該執(zhí)行的操作痛侍，請求URL描述了要對哪個資源執(zhí)行這個方法朝氓。請求行中還包含HTTP的版本，用來告知服務器主届，客戶端使用的是哪種HTTP赵哲。

• 響應行
  響應報文承載了狀態(tài)信息和操作產(chǎn)生的所有結果數(shù)據(jù)，將其返回給客戶端君丁。響應報文的起始行枫夺，或稱為響應行，包含了響應報文使用的HTTP版本绘闷、數(shù)字狀態(tài)碼橡庞，以及描述操作狀態(tài)的文本形式的原因短語。

• 起始行中各部分介紹：

  • method（方法）

    • 客戶端希望服務器對資源執(zhí)行的動作印蔗。是一個單獨的詞扒最，比如GET /specials/saw-blade.gif HTTP/1.0,方法就是GET。
    • 根據(jù)HTTP標準华嘹，HTTP請求可以使用多種請求方法吧趣。
      HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
      HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法耙厚。
    • 具體方法如下：
      1. GET 請求指定的頁面信息强挫，并返回實體主體。
      2. HEAD 類似于get請求薛躬，但只返回首部俯渤，不會返回實體的主體部分。這就允許客戶端在為獲取實際資源的情況下泛豪，對資源的首部進行檢查稠诲。
         使用HEAD，可以：

        - 在不獲取資源的情況下了解資源的情況（比如诡曙，判斷其類型）臀叙；
        - 通過查看響應中的狀態(tài)碼，看看某個對象是否存在价卤；
        - 通過查看首部劝萤，測試資源是否被修改了。
      

      3. POST 向指定資源提交數(shù)據(jù)進行處理請求（例如提交表單或者上傳文件）慎璧。數(shù)據(jù)被包含在請求體中床嫌。POST請求可能會導致新的資源的建立和/或已有資源的修改跨释。
      4. PUT 從客戶端向服務器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容（即向服務器上的資源中存儲數(shù)據(jù)）。
      5. DELETE 請求服務器刪除指定的頁面厌处。
      6. CONNECT HTTP/1.1協(xié)議中預留給能夠將連接改為管道方式的代理服務器鳖谈。
      7. OPTIONS 允許客戶端查看服務器的性能。
      8. TRACE 回顯服務器收到的請求阔涉，主要用于測試或診斷缆娃。

  • request-URL（請求URL）
    命名了所請求的資源，或者URL路徑組件的完整URL瑰排。如果直接與服務器進行對話贯要，只要URL的路徑組件是資源的絕對路徑，通常就不會有什么問題——服務器可以假定自己是URL的主機/端口椭住。

  • version（版本）
    報文所使用的HTTP版本崇渗，其格式看起來是這樣的：

      HTTP/<major>.<minor>
    

  其中主要版本號（major）和次要版本號（minor）都是整數(shù)。
  版本號說明了應用程序支持的最高HTTP版本京郑。

  注意：版本號不會被當作小數(shù)來處理宅广，比較時要依次比較主要版本號和次要版本號的大小。
  - status-code（狀態(tài)碼）
  方法是用來告訴服務器做什么事情的些举，狀態(tài)碼則用來告訴客戶端乘碑，發(fā)生了什么事情。
  比如金拒，在行HTTP/1.0 200 OK中，狀態(tài)碼就是200套腹。
  這三位數(shù)字描述了請求過程中所發(fā)生的情況绪抛。每個狀態(tài)碼的第一位數(shù)字都用于描述狀態(tài)的一般類別（“成功”、“出錯”等）电禀。
  HTTP狀態(tài)碼由三個十進制數(shù)字組成幢码，第一個十進制數(shù)字定義了狀態(tài)碼的類型，后兩個數(shù)字沒有分類的作用尖飞。

    - HTTP狀態(tài)碼共分為5種類型：
        - 1XX.  信息症副，服務器收到請求，需要請求者繼續(xù)執(zhí)行操作
        - 2XX. 成功政基，操作被成功接收并處理
        - 3XX.    重定向贞铣，需要進一步的操作以完成請求
        - 4XX.    客戶端錯誤，請求包含語法錯誤或無法完成請求
        - 5XX.    服務器錯誤沮明，服務器在處理請求的過程中發(fā)生了錯誤
        
    - HTTP常用狀態(tài)碼：
        - 200 成功辕坝。請求的所有數(shù)據(jù)都在響應主體中。 
        - 301 資源（網(wǎng)頁等）被永久轉移到其它URL
        - 401 需要輸入用戶名和密碼荐健。
        - 404 NOT FOUND 服務器無法找到所請求URL對應的資源酱畅。（**最常見**）
        - 500 內(nèi)部服務器    錯誤
  

  相關鏈接：HTTP狀態(tài)碼大全

  • reason-phrase（原因短語）
    數(shù)字狀態(tài)碼的可讀版本琳袄，包含行終止序列之前的所有文本。原因短語只對人類有意義纺酸，比如HTTP/1.0 200 NOT OK和HTTP/1.0 200 OK中原因短語NOT OK和OK含義不同窖逗，但都會被計算機當作成功指示處理。HTTP規(guī)范并沒有提供任何硬性規(guī)定要求原因短語以何種形式出現(xiàn)餐蔬。

header（首部）

1. 可以有零個或多個首部碎紊，每個首部包含一個名字，后面跟著冒號（:）用含，然后是一個可選的空格矮慕，接著是一個值，最后是一個CRLF啄骇。首部是由由一個空行(CRLF）結束的痴鳄，這個空行(CRLF)表示了首部列表的結束和實體主體部分的開始。

2. HTTP首部字段向請求和響應報文中添加了一些附加信息缸夹。本質上說痪寻，它們只是一些名/值對的列表。

3. 例如：

    HTTP/1.1 200 OK
    Server: nginx
    Date: Tue, 06 Sep 2016 08:56:08 GMT
    Content-Type: text/xml; charset=utf-8
    Vary: Accept-Encoding
    Content-Language: zh-CN
    Content-Encoding: gzip
   

4. 可以將首部分為五個主要的類型虽惭。

   • 通用首部
     有些首部提供了與報文相關的最基本的信息橡类，無論報文是什么類型都可以為其提供一些有用信息，它們被稱為通用首部芽唇。
     例如：
     Date: Tue, 06 Sep 2016 08:56:08 GMT

   通用緩存首部：

   1. Cache-Control 指定請求和響應遵循的緩存機制
      Cache-Control: no-cache
   2. Pragma 用來包含實現(xiàn)特定的指令
      Pragma: no-cache

   從技術角度來看顾画，Pragma是一種請求首部，但經(jīng)常被錯誤地用于響應首部匆笤，在任何情況下Cache-Control的使用都優(yōu)于Pragma研侣。
   - 請求首部
   只在請求報文中有意義的首部。用于說明是誰或什么在發(fā)送請求炮捧、請求源自何處庶诡，或者客戶端的喜好及能力。服務器可以根據(jù)請求首部給出的客戶端信息咆课，試著為客戶端提供更好的響應末誓。
   請求的信息性首部：
   - From 發(fā)出請求的用戶的Email
   From: user@email.com
   - Host 指定請求的服務器的域名和端口號
   Host: www.zcmhi.com
   - Referer 先前網(wǎng)頁的地址，當前請求網(wǎng)頁緊隨其后,即來路
   Referer: http://www.zcmhi.com/archives/71.html
   - User-Agent User-Agent的內(nèi)容包含發(fā)出請求的用戶信息
   User-Agent: Mozilla/5.0 (Linux; X11)

    1. Accept首部
    為客戶端提供了一種將其喜好和能力告知服務器的方式书蚪，包括它們想要什么喇澡，可以使用什么，以及最重要的善炫，它們不想要什么撩幽。這樣服務器就可以根據(jù)這些額外信息，對要發(fā)送的內(nèi)容作出更明智的決定。Accept首部會使連接的兩端都收益窜醉∠芴眩客戶端會得到它們想要的內(nèi)容，服務器則不會浪費其時間和帶寬來發(fā)送客戶端無法使用的東西榨惰。
        下面列出各種Accept首部：
        - Accept    指定客戶端能夠接收的內(nèi)容類型    
                Accept: text/plain, text/html
        - Accept-Charset    瀏覽器可以接受的字符編碼集拜英。
                Accept-Charset: iso-8859-5
        - Accept-Encoding    指定瀏覽器可以支持的web服務器返回內(nèi)容壓縮編碼類型。    
                Accept-Encoding: compress, gzip
        - Accept-Language    瀏覽器可接受的語言    
                Accept-Language: en,zh
        - Accept-Ranges    可以請求網(wǎng)頁實體的一個或者多個子范圍字
                Accept-Ranges: bytes
        - TE    客戶端愿意接受的傳輸編碼琅催，并通知服務器接受接受尾加頭信息    
                TE: trailers,deflate;q=0.5
    2. 條件請求首部
    有時客戶端希望為請求加上某些限制居凶。比如，如果客戶端已經(jīng)有了一份文檔副本藤抡，就希望只在服務器上的文檔與客戶端擁有的副本有所區(qū)別時侠碧，才請求服務器傳輸文檔。
        - Expect    請求的特定的服務器行為    
                Expect: 100-continue
        - If-Match    只有請求內(nèi)容與實體相匹配才有效    
                If-Match: “737060cd8c284d8af7ad3082f209582d”
        - If-Modified-Since    如果請求的部分在指定時間之后被修改則請求成功缠黍，未被修改則返回304代碼    
                If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
        - If-None-Match    如果內(nèi)容未改變返回304代碼弄兜，參數(shù)為服務器先前發(fā)送的Etag，與服務器回應的Etag比較判斷是否改變    
                If-None-Match: “737060cd8c284d8af7ad3082f209582d”
        - If-Range    如果實體未改變瓷式，服務器發(fā)送客戶端丟失的部分替饿，否則發(fā)送整個實體。參數(shù)也為Etag    
                If-Range: “737060cd8c284d8af7ad3082f209582d”
        - If-Unmodified-Since    只在實體在指定時間之后未被修改才請求成功    
                If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
        - Range    只請求實體的一部分贸典，指定范圍    
                Range: bytes=500-999
    3. 安全請求首部
    HTTP本身就支持一種簡單的機制视卢，可以對請求進行質詢/響應認證。這種機制要求客戶端在獲取特定的資源之前廊驼，先對自身進行認證据过，這樣就可以使事務稍微安全一些。
        - Authorization    HTTP授權的授權證書    
                Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
        - Cookie    HTTP請求發(fā)送時妒挎，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務器蝶俱。    
                Cookie: $Version=1; Skin=new;
    4. 代理請求首部
    隨著因特網(wǎng)上代理的普遍應用，人們定義了幾個首部來協(xié)助其更好地工作饥漫。
        - Max-Forwards    限制信息通過代理和網(wǎng)關傳送的時間    Max-Forwards: 10
        - Proxy-Authorization    連接到代理的授權證書    Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
   

   • 響應首部
     響應首部為客戶端提供了一些額外信息，比如誰在發(fā)送響應罗标、響應者的功能庸队，甚至于響應相關的一些特殊指令。這些首部有助于客戶端處理響應闯割，并在將來發(fā)起更好的請求彻消。
     響應的信息性首部
     • Age 從原始服務器到代理緩存形成的估算時間（以秒計，非負）
       Age: 12
     • Retry-After 如果實體暫時不可取宙拉，通知客戶端在指定時間之后再次嘗試
       Retry-After: 120
     • Server web服務器軟件名稱
       Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
     • Warning 警告實體可能存在的問題
       Warning: 199 Miscellaneous warning
     1. 協(xié)商首部
        如果資源有多種表示方法——比如宾尚，如果服務器上有某文檔的法語和德語譯稿，HTTP/1.1可以為服務器和客戶端提供對資源進行協(xié)商能力。
        • Accept-Ranges 表明服務器是否支持指定范圍請求及哪種類型的分段請求
          Accept-Ranges: bytes
        • Vary 告訴下游代理是使用緩存響應還是從原始服務器請求
          Vary: *
     2. 安全響應首部
        即HTTP的質詢/響應認證機制的響應側』吞現(xiàn)在介紹一些基本的質詢首部御板。
        • Proxy-Authenticate 它指出認證方案和可應用到代理的該URL上的參數(shù)
          Proxy-Authenticate: Basic
        • Set-Cookie 設置Http Cookie
          Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
        • WWW-Authenticate 表明客戶端請求實體應該使用的授權方案
          WWW-Authenticate: Basic
   • 實體首部
     有很多首部可以用來描述HTTP報文的負荷（即entity-body）。由于請求和響應報文中都可能包含實體部分牛郑，所以在這兩類類型的報文中都有可能出現(xiàn)實體首部怠肋。
     實體的信息性首部
     • Allow 對某網(wǎng)絡資源的有效的請求行為，不允許則返回405
       Allow: GET, HEAD
     • Location 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源
       Location: http://www.zcmhi.com/archives/94.html
     1. 內(nèi)容首部
        內(nèi)容首部提供了與實體內(nèi)容有關的特定信息淹朋，說明了其類型笙各、尺寸以及處理它所需的其他有用信息胧后。
        • Content-Encoding web服務器支持的返回內(nèi)容壓縮編碼類型肉微。
          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 在整個返回體中本部分的字節(jié)位置
          Content-Range: bytes 21010-47021/47022
        • Content-Type 返回內(nèi)容的MIME類型
          Content-Type: text/html; charset=utf-8
     2. 實體緩存首部
        通用的緩存首部說明了如何或什么時候進行緩存。實體的緩存首部提供了與背緩存實體有關的信息——比如庆捺，驗證已緩存的資源副本是否仍然有效所需的信息仑性，以及更好地估計已緩存資源何時失效所需的線索惶楼。
        • 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
   • 擴展首部
     擴展首部是非標準的首部，由應用程序開發(fā)者創(chuàng)建虏缸，但還未添加到已批準的HTTP規(guī)范中去鲫懒。即使不知道這些擴展首部的含義，HTTP程序也要接受它們并對其進行轉發(fā)刽辙。

相關鏈接：HTTP響應頭和請求頭信息對照表
注意：因為協(xié)議不同窥岩，有的首部沒有給出。

entity-body（實體的主體部分）

1. 包含一個由任意數(shù)據(jù)組成的數(shù)據(jù)塊宰缤。并不是所有報文都包含實體的主體部分颂翼。
   實體的主體是HTTP報文的負荷。就是HTTP要傳輸?shù)膬?nèi)容慨灭。
2. HTTP報文可以承載很多類型的數(shù)字數(shù)據(jù)：圖片朦乏、視頻、HTML文檔氧骤、軟件應用程序呻疹、信用卡事物、電子郵件等筹陵。

如何查看HTTP報文刽锤？

• 打開Chrome瀏覽器，點擊右上角“三”按鈕朦佩。
• 點擊工具-----再點擊開發(fā)者工具
• 找到Network選項框并思。
• 點擊你所需要查看的請求流即可。
  相關鏈接：如何查看HTTP請求頭