05 前端HTTP协议(图解HTTP) 之 HTTP首部
1. HTTP 報文
HTTP報文 = 報文首部 + '空行（CR+LF）' + 報文主體 復制代碼2. HTTP首部字段類型
HTTP首部字段是構成HTTP報文的要素之一。在客戶端和服務器端以HTTP協議進行通信的過程中，無論是請求還是響應：都會使用首部字段，它能起到傳遞額外重要信息的作用。
- 通用首部字段（General Header Fileds）: 請求和響應報文都會使用的首部
- 請求首部字段（Request Header Fields）: 從客戶端發起請求時使用。補充了請求的附加內容，客戶端信息，響應內容相關優先級。
- 響應首部字段（Response Header Fields）: 從服務端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的信息。
- 實體首部字段（Entity Header Fields）: 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等于實體有關的信息。
3 通用首部字段
3.1 Cache-Control
// 操作緩存的工作機制。參數使用`,`分割 Cache-Control: private, max-age=0, no-cache 復制代碼
public : 表明其他用戶可以利用緩存
private: 表明只能特定用戶作為對象（與public相反）。緩存服務器會對特定用戶提供緩存的服務，對于其他用戶發過來的請求，代理服務器不會返回緩存。
no-cache:從字面意義上很容易誤解為不緩存，但是no-cache代表不緩存過期的資源，緩存會向服務器進行有效處理確認之后處理資源
- 客戶端請求包含no-cache,表示不接受緩存過的響應。
- 中間緩存服務器必須將客戶端請求轉發給源服務器
- 服務器返回中包含no-cache,表明緩存服務器不能對資源進行緩存，并且以后不再對緩存服務器提出的資源有效性進行確認。
- 服務器返回的no-cache=Location,指定了具體參數值，客戶端接收到這個指定參數值的首部字段對應的響應報文后，不能使用緩存。如果服務器返回的no-cache無參數的首部字段是可以緩存的。
no-store: 規定緩存不能再本地存儲請求或響應的一部分。
s-maxage(單位秒): s-maxage指令的功能和 max-age 指令的相同，但s-maxage只適用于供多位用戶使用的公共緩存服務器（一般指代理），該指令存在會直接接忽略對Expires 首部字段及max-age 指令的處理。
max-age(單位秒): HTTP/1.1的緩存服務器遇到max-age指令，會忽略Expires首部，HTTP/1.0下相反
- 當客戶端發起請求包含max-age指令，如果資源緩存時間比指定的時間小，客戶端接收緩存資源。如果max-age=0,緩存服務器需要將請求轉發給源服務器
- 當服務端返回響應包含max-age指令，緩存服務器將不對資源有效性進行再次確認，max-age代表緩存最長時間
min-fresh(單位秒): 要求緩存服務器返回小于指定時間的緩存資源。例如min-fresh=60,過了60秒的資源無法作為響應返回。
max-stale(單位秒)：緩存的資源即使過期了也照常接收。
- 未指定參數，無論過多久，客戶端都會響應
- 指定具體值，那么即使過期，但人處于max-stale指定的時間內，仍會被客戶端接收。
only-if-cached: 表示客戶端 請求資源 僅在緩存服務器本地 存在緩存，不需要緩存服務器重新加載響應，也不需要確認資源有效性直接返回，如果不存在緩存，則返回狀態碼504 Gateway Timeout。
must-revalidate: 會忽略max-stale指令， 代理服務器會向源服務器再次驗證 請求的響應緩存目前任然有效。代理服務器連接源服務器異常，返回504 Gateway Timeout。執行對象是被請求的代理服務器
proxy-revalidate: 要求所有的緩存服務器在接收到客戶端帶有該指令的請求返回響應之前， 必須再次驗證緩存的有效性。例如當用戶登錄，需要所有緩存代理服務器都更新文件，而不是只有被請求的緩存服務器更新。
no-transform: 無論是請求，還是響應，緩存都不能更改實體主體的媒體類型（可防止緩存或代理 去壓縮圖片等操作）。
cache-extension token:
通過cache-extension 標記(token),可擴展Cache-Control首部字段內的指令。如下：如果緩存服務器不能理解commutity這個新指令，則直接忽略。因此extension tokens 只對能識別它的緩存服務器有效。
3.2 Connection
Connection 首部： 控制不再轉發給代理的首部字段 和 管理持久化連接。
- 客戶端發送請求和服務器返回響應 內，使用Connection首部字段，控制不再轉發的首部字段（即Hop-by-hop）。
- 管理持久化連接: HTTP/1.1默認連接是keep-alive持久連接，當服務器想明確斷開連接，使用Connection: close
3.3 其他 通用首部字段
首部字段Date: 創建HTTP報文的日期和事件。
Pragma： 僅為兼容歷史版本而存在。Pragma: no-cache
Trailer: 事先說明在報文主體后記錄了哪些首部字段。 該首部字段可應用在 HTTP/1.1 版本分塊傳輸編碼時。
Transfer-Encoding: 規定傳輸報文主體時采用的編碼方式。僅對分塊傳輸編碼有效。
Upgrade: 用于檢測HTTP協議及其他協議是否可使用更高的版本進行通信。
Via： 在經過代理時附加該首部字段內容。追蹤客戶端與服務器之前的請求和響應報文的傳輸路徑
- 經常會和 TRACE 方法一起使用。如， 代理服務器接收到由 TRACE 方法發送過來的請求（其中Max-Forwards: 0） 時， 代理服務器就不能再轉發該請求了。 這種情況下， 代理服務器會將自身的信息附加到 Via 首部后， 返回該請求的響應。
Warning: 告知用戶一些與緩存相關的警告問題。
4. 請求首部字段
q:表示權重，范圍0-1，值越大權重越高。Accept-xxx 都可以使用權重來控制。
| Accept | "通知服務器，用戶代理能夠處理的媒體類型和媒體類型的相對優先級 | type/subtype 格式" "文本類型：text/html ,text/plain,text/css,application/xhtm+xml,applciation/xml 圖片文件：image/jpeg,image/gif,image/png 視頻文件：video/mpeg,video/quicktime 應用程序使用的二進制文件：application/octet-stream,application/zip |
| Accept-Charset | 通知服務器用戶代理支持的字符集及字符集的相對優先順序 | Accept-Charset:iso-8895-5,unicode-1-1; |
| Accept-Encoding | 告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序 | gzip: 由文件壓縮程序gzip(GNU zip)生成的編碼格式 compress: 由UNIX文件壓縮程序compress生成的編碼格式 deflate：組合使用 zlib 格式（RFC1950） 及由 deflate 壓縮算法（RFC1951） 生成的編碼格式 identity: 不執行壓縮或不會變化的默認編碼格式 |
| Accept-Language | 告知服務器用戶代理能夠處理的自然語言集（指中文或英文等),以及自然語言集的相對優先級 | Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3 |
| Authorization | 告知服務器， 用戶代理的認證信息（證書值） | GET /index.html Ahtorization: Basic dWVub3NlbjpwYXNzd29yZA== |
| Expect | 告知服務器， 期望出現的某種特定行為 | HTTP/1.1 規范只定義了 100-continue（狀態碼 100 Continue 之意） |
| Form | 告知服務器使用用戶代理的用戶的電子郵件地址。目的就是為了顯示搜索引擎等用戶代理的負責人的電子郵件聯系方式 | Form: aa@qq.com |
| Host | 同一個IP 服務器部署這多個域名， 使用首部字段 Host 加以區分。 | Host: www.hackr.jp |
| Max-Forwards | 以十進制整數形式指定可經過服務器最大的數目。 通過TRACE 或OPTION 方法，沒經過一個服務器值減1。 當值為0時不再轉發，直接返回響應 | Max-Forwards：10 |
| Proxy-Authorization | 接收從代理服務器發來的認證查詢時， 客戶端會發送包含首部字段Proxy-Authorization 的請求， 以告知服務器認證所需要的信息 | Proxy-Authorization: Basic dGlwOjkpNLAGfFY5 |
| Range | 對于只需獲取部分資源的范圍請求， 包含首部字段 Range 即可告知服務器資源的指定范圍 | Range: bytes=5001-10000 |
| Referer | 首部字段 Referer 會告知服務器請求的原始資源的 URI | |
| TE | 告知服務器，客戶端能夠處理響應的傳輸編碼方式及相對優先級。 它和首部字段Accept-Encoding很像，但是用于傳輸編碼 | TE: gzip,deflate;q=0.5 |
| User-Agent | 用于傳達瀏覽器的種類 | User-Agent: Mozilla/5.0 (Window NT 6.1; wow64;rv:13.0)... |
If-XXX
附帶條件請求：形如If-xxx樣式的請求首部字段成為條件請求。服務器接收到附帶條件的請求后，只有判斷指定條件為真時，才回執行請求。
| If-Match | 只有If-Match的字段值和ETag值匹配，服務器才接受請求 | 客戶端請求: Get /Index.html If-Match:'123456' 服務器： 匹配資源所用的實體標記(ETag)值，一致執行請求返回資源，否則返回狀態碼412 Precondition Failed If-Match:*,服務器會忽略ETag 如果需要獲取到資源，則在返回狀態碼412后，還需要再次發起請求get /index.html,才能獲取到新的資源 |
| If-Modified-Since | 指定日期時間后，資源費發生了更新，服務端會接收請求。 用來確認代理或客戶端擁有的本地資源的有效性。 | 客戶端請求: Get /Index.html If-Modified-Since:Thu,15 Apr 2012 00:00:00 GMT 服務端： 有修改返回：200 ok Last-Modified: Sun,29 Aug 2012 00:00:12 GMT 無修改返回 304 Not Modified |
| If-None-Match | 只有在 If-None-Match 的字段值與 ETag 值不一致時， 可處理該請求。 如果一致，就返回304，表示告知客戶端使用自己本地的緩存。 在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資源。 因此，這與使用首部字段 If-Modified-Since 時有些類似 | 客戶端請求: Get /Index.html If-None-Match: '123456' 服務端： ETag不一致：服務端處理，返回最新的數據 一致則返回304，客戶端使用自己本地緩存 |
| If-Range | 告知服務器若指定的 IfRange 字段值(ETag 值或者時間) 和請求資源的ETag值或時間相一致時,則作為范圍請求處理。 反之，則返回全體資源 | 客戶端: GET /index.html If-Range:'123456' Range: byte=5001-10000 服務端 ETag=123456： 206 Partial Content Content-Range: bytes 5001-10000/10000 Content-Length:5000 服務器 ETag=567890: 200 OK ETag: '567890' |
| If-Unmodified-Since | 告知服務器，請求的資源在字段值指定的日期之后，未發生更新的請求才處理請求。 如果指定日期后發生了更新，則以狀態碼412 Preconditino Failed 響應 | 客戶端： Get /index.html If-Unmodified-Since:Thu,15 Apr 2012 00:00:00 GMT 服務端時間內無修改： 200 ok 服務端時間內有修改： 412 Precondition Failed |
5. 響應首部字段
| Accept-Ranges | 告知客戶端，服務器端是否能夠處理范圍請求，以指定獲取服務器端某個部分的資源 | Accept-Ranges:bytes/none (none表示不能處理) |
| Age | 告訴客戶端，源服務器在多久前創建了響應。單位秒。 若創建該響應的服務器是緩存服務器， Age 值是指緩存后的響應再次發起認證到認證完成的時間值。 代理創建響應時必須加上首部字段Age。 | Age:600 |
| ETag | 它是一種可將資源以字符串形式做唯一性標識的方式。服務器會為每份資源分配對應的 ETag 值。 當資源更新時，ETag 值也需要更新。生成 ETag 值時，并沒有 統一的算法規則，而僅僅是由服務器來分配 資源被緩存時，就會被分配唯一性標識。ETag 中有強 ETag 值和弱 ETag 值之分： -強 ETag 值: 不論實體發生多么細微的變化都會改變其值。ETag: "usagi-1234" -弱 ETag 值: 只用于提示資源是否相同。只有資源發生了根本改變，產 生差異時才會改變 ETag 值。這時，會在字段值最開始處附加 W/。ETag: W/"usagi-1234" | ETag: "usagi-1234" |
| Location | 將響應接收方引導至某個與請求 URI 位置不同的資源 一般配合3xx：Redirection，提供重定向URI,瀏覽器會強制性嘗試訪問重定向資源 | Location: www.xxx.com |
| proxy-Authenticate | 會把由代理服務器所要求的認證信息發送給客戶端 | Proxy-Authenticate: Basic realm="Usagidesign Auth" |
| Retry-After | 告訴客戶端應該多久之后再次發起請求，配合狀態碼503 Service Unavailable或3xx Redirect | Retry-After:120(單位秒),Retry-After:Wed 04 Jul 2012 06:32:23 GMT |
| Server | 告知客戶端，當前服務器上安裝的HTTP服務器應用程序的信息 | Server: Apache/2.2.6 (Unix) PHP/5.2.5 |
| WWW-Authenticate | 用于 HTTP 訪問認證。 它會告知客戶端用于訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest） 和帶參數提示的質詢（challenge） 。 狀態碼 401 Unauthorized 響應中，肯定帶有首部字段 WWW-Authenticate | |
| Vary | 首部字段Vary可對緩存進行控制，源服務器 向 代理服務器傳達關于本地返還使用方法的命令: -代理服務器收到源服務器Vary:Accept-Language,若要進行緩存，則只緩存Accept-Language中可接受的語言的對應的文件進行緩存（en：則緩存英文）。 如果緩存服務器的緩存資源和Vary指定的首部字段不同，則需要重新沖源服務器中獲取 | Vary: Accept-Language |
6. 實體首部字段
| Allow | 用于通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法 | Allow: GET,HEAD |
| Content-Encoding | 告知客戶端服務器對實體的主體部分選用的內容編碼方式 | Content-Encoding: gzip |
| Content-Language | 告訴客戶端實體主體使用的自然語言 | Content-Language:zh-CN |
| Content-Length | 實體主體部分的大小。對實體主體進行內容編碼傳輸時，不能再使用Content-Length | Content-Length: 1500 |
| Content-Location | 給出與報文主體部分相對應的 URI。與首部字段Location不同，表示的是報文主體返回資源對應的URI | Content-Location:http:www.xx |
| Content-MD5 | 客戶端會將接受到的主體實體執行相同的MD5算法，然后與首部字段Content-MD5字段值進行比較。 這種方式其實無法判斷內容是否被篡改：因為主體實體被篡改，而Content-MD5也可能被篡改 | Content-MD5:OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY== |
| Content-Range | 針對范圍請求時，通過Content-Range告訴客戶端返回的實體的哪部分符合范圍請求 | Content-Range: bytes 5001-10000/10000 |
| Content-Type | 告知客戶端實體主體內對象的媒體類型。 媒體類型和Accept一樣，字段使用type-subtype形式賦值 參數charset:使用iso-8859-1 等字符集進行賦值 | Content-Type: text/html;charset=UTF-8 |
| Expires | 告訴客戶端，該資源的失效日期。 換存服務器接收到該首部，在過期之前一直會以緩存來應答請求。超過該日期，緩存服務器會轉向源服務器獲取請求資源 | Exipires: Wed, 04 Jul 2012 08:26:05 GMT |
| Last-Modified | 指明資源最終修改時間 | Last-Modified: Wed, 23 May 2012 09:59:55 GMT |
8. End-to-end 首部和Hop-by-hop首部
HTTP首部字段將定義緩存代理和非緩存代理的行為。
逐跳首部(Hop-by-hop Header): 該類首部支隊單次轉發有效，會因通過緩存或代理而不再轉發。HTTP/1.1后如果要使用Hop-by-hop首部，需提供Connection首部字段。
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
端到端首部(End-to-end Header): 除上面的逐跳首部，都屬于該類。分到該類的首部會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規定它必須被轉發。
8. 非HTTP/1.1首部字段
Cookie：請求首部字段，服務器接收到的Cookie信息，同樣可以以多個 Cookie 形式發送
set-Cookie： 開始狀態管理所使用的Cookie信息，響應首部字段
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 復制代碼| expires | 指定瀏覽器可發送Cookie的有效日期 當expires省略，有效期僅限于維持瀏覽器會話(Session)時間段內，通常用于瀏覽器關閉之前 |
| path | path 屬性可用于限制指定 Cookie 的發送范圍的文件目錄 不過另有辦法可避開這項限制， 看來對其作為安全機制的效果不能抱有期待 |
| domain | 指定的域名可做到與結尾匹配一致。 例如當指定example.com后，除了該域名，www.example.com 或www2.expample.com等都可以發送cookie |
| secure | 限制 Web 頁面僅在 HTTPS 安全連接時， 才可以發送 Cookie。當無該屬性，不論是http,還是https都可以回收該行為 例如：Set-Cookie: name=value; secure，僅當在https://www.example.com/（HTTPS） 安全連接的情況下才會進行 Cookie 的回收 |
| HttpOnly | 它使 JavaScript 腳本無法獲得 Cookie。 其主要目的為防止跨站腳本攻擊（Cross-sitescripting， XSS） 對 Cookie 的信息竊取 例如：Set-Cookie: name=zhaoxxx; HttpOnly,在Web頁面可以對Cookie進行讀取操作，但是使用javascript的document.cookie就無法讀取。因此也就無法在 XSS 中利用 JavaScript 劫持Cookie 了 |
Content-Disposition： 指示服務器回復的內容該以何種形式展示，是以內聯的形式（即網頁或者頁面的一部分），還是以附件的形式下載并保存到本地。
9. 其他首部字段
| X-Frame-Options(響應首部) | 用于控制網站內容在其他 Web 網站的 Frame 標簽內的顯示問題。其主要目的是為了防止點擊劫持（clickjacking） 攻擊。 DENY: 拒絕，SAMEORIGIN:僅同源域名下的頁面允許顯示加載，其他域名則不行 |
| X-XSS-Protection(響應首部) | 是針對跨站腳本攻擊（XSS） 的一種對策， 用于控制瀏覽器 XSS 防護機制的開關 0:將XSS過來設置為無效狀態，1：將XSS過濾設置成有效狀態 |
| DNT(請求首部) | 其中DNT(Do Not Track),拒絕個人信息被收集，表示拒絕被精準廣告追蹤的一種方法 0: 同意被追蹤，1：拒絕被追蹤 |
| P3P(響應首部) | P3P（The Platform forPrivacy Preferences， 在線隱私偏好平臺） 技術，可以讓 Web 網站上的個人隱私變成一種僅供程序可理解的形式， 以達到保護用戶隱私的目的。P3P設定步驟： 1：創建P3P隱私 2: 創建P3P隱私對照文件后，保存命名在/w3c/p3p.xml 3：從P3P隱私中新建Compact plicies后，輸出到HTTP響應中 |
總結
以上是生活随笔為你收集整理的05 前端HTTP协议(图解HTTP) 之 HTTP首部的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 截图后粘贴或拖拽上传
- 下一篇： 2017年html5行业报告,云适配发布