HTTP頭字段

求聞百科,共筆求聞

HTTP頭字段(英語:HTTP header fields)是指在超文本傳輸協議(HTTP)的請求和響應消息中的消息頭部分。它們定義了一個超文本傳輸協議事務中的操作參數。HTTP頭部字段可以自己根據需要定義,因此可能在 Web 伺服器和瀏覽器上發現非標準的頭字段。

基本格式

協議頭的字段,是在請求(request)或響應(response)行(一條消息的第一行內容)之後傳輸的。協議頭的字段是以明文的字符串格式傳輸,是以冒號分隔的鍵名與鍵值對,以回車(CR)加換行(LF)符號序列結尾。協議頭部分的結尾以一個空白字段標識,結果就是,也就是傳輸兩個連續的CR+LF。在歷史上,很長的行曾經可能以多個短行的形式傳輸;在下一行的開頭,輸出一個空格(SP)或者一個水平制表符(HT),表示它是一個後續行。在如今,這種換行形式已經被廢棄[1]

類型

HTTP 頭字段根據實際用途被分為以下 4 種類型:

  • 通用頭字段(英語:General Header Fields)
  • 請求頭字段(英語:Request Header Fields)
  • 響應頭字段(英語:Response Header Fields)
  • 實體頭字段(英語:Entity Header Fields)

字段名

在 RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234 和 RFC 7235 中,對一組核心字段進行了標準化。有一份對於這些字段的官方的登記冊,以及 一系列的補充規範 ,由互聯網號碼分配局(IANA)維護。各個應用程式也可以自行定義額外的字段名字及相應的值。頭字段的永久登記表臨時登記表目前由IANA維護。其他的字段名稱和允許的值可以由各應用程式定義。

按照慣例,非標準的協議頭字段是在字段名稱前加上X-[2]前綴來標識。但這一慣例已在2012年6月被廢棄,因為按照這種慣例,非標準字段變成標準字段時會引起很多不方便之處。[3]以前曾經有的使用Downgraded-的限制也在2013年3月被解除。[4]

字段值

某些字段中可以包含註釋內容(例如User-Agent、Server和Via字段中),這些註釋內容可由應用程式忽略[5]

很多字段的值中可以包含帶有權重的質量(quality,常被簡稱為Q)的鍵值對,指定的「重量」會在內容協商的過程中使用[6]

大小限制

標準中沒有對每個協議頭字段的名稱和值的大小設置任何限制,也沒有限制字段的個數。然而,出於實際場景及安全性的考慮,大部分的伺服器、客戶端和代理軟件都會實施一些限制。例如,Apache 2.3伺服器在默認情況下限制每個字段的大小不得超過8190位元組,同時,單個請求中最多有100個頭字段[7]

請求字段

協議頭字段名 說明 示例 狀態
Accept 能夠接受的回應內容類型(Content-Types)。參見內容協商 Accept: text/plain 常設
Accept-Charset 能夠接受的字符集 Accept-Charset: utf-8 常設
Accept-Encoding 能夠接受的編碼方式列表。參考HTTP壓縮 Accept-Encoding: gzip, deflate 常設
Accept-Language 能夠接受的回應內容的自然語言列表。參考 內容協商 Accept-Language: en-US 常設
Accept-Datetime 能夠接受的按照時間來表示的版本 Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 臨時
Authorization 用於超文本傳輸協議的認證的認證信息 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 常設
Cache-Control 用來指定在這次的請求/響應鏈中的所有緩存機制 都必須 遵守的指令 Cache-Control: no-cache 常設
Connection 該瀏覽器想要優先使用的連接類型

[8]

Connection: keep-alive

Connection: Upgrade

常設
Cookie 之前由伺服器通過 Set- Cookie (下文詳述)發送的一個 超文本傳輸協議Cookie Cookie: $Version=1; Skin=new; 常設: 標準
Content-Length 以 八位字節數組 (8位的字節)表示的請求體的長度 Content-Length: 348 常設
Content-MD5 請求體的內容的二進制 MD5 散列值,以 Base64 編碼的結果 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 過時的[9]
Content-Type 請求體的 MIME類型 (用於POST和PUT請求中) Content-Type: application/x-www-form-urlencoded 常設
Date 發送該消息的日期和時間(按照 RFC 7231 中定義的"超文本傳輸協議日期"格式來發送) Date: Tue, 15 Nov 1994 08:12:31 GMT 常設
Expect 表明客戶端要求伺服器做出特定的行為 Expect: 100-continue 常設
From 發起此請求的用戶的郵件地址 From: user@example.com 常設
Host 伺服器的域名(用於虛擬主機 ),以及伺服器所監聽的傳輸控制協議端口號。如果所請求的端口是對應的服務的標準端口,則端口號可被省略。

[10]自超文件傳輸協議版本1.1(HTTP/1.1)開始便是必需字段。

Host: zh.wikipedia.org:80

Host: zh.wikipedia.org

常設
If-Match 僅當客戶端提供的實體與伺服器上對應的實體相匹配時,才進行對應的操作。主要作用時,用作像 PUT 這樣的方法中,僅當從用戶上次更新某個資源以來,該資源未被修改的情況下,才更新該資源。 If-Match: "737060cd8c284d8af7ad3082f209582d" 常設
If-Modified-Since 允許在對應的內容未被修改的情況下返回304未修改( 304 Not Modified ) If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 常設
If-None-Match 允許在對應的內容未被修改的情況下返回304未修改( 304 Not Modified ),參考 超文本傳輸協議 的實體標記 If-None-Match: "737060cd8c284d8af7ad3082f209582d" 常設
If-Range 如果該實體未被修改過,則向我發送我所缺少的那一個或多個部分;否則,發送整個新的實體 If-Range: "737060cd8c284d8af7ad3082f209582d" 常設
If-Unmodified-Since 僅當該實體自某個特定時間已來未被修改的情況下,才發送回應。 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 常設
Max-Forwards 限制該消息可被代理及網關轉發的次數。 Max-Forwards: 10 常設
Origin 發起一個針對 跨來源資源共享 的請求(要求伺服器在回應中加入一個『訪問控制-允許來源』('Access-Control-Allow-Origin')字段)。 Origin: http://www.example-social-network.com 常設: 標準
Pragma 與具體的實現相關,這些字段可能在請求/回應鏈中的任何時候產生多種效果。 Pragma: no-cache 常設但不常用
Proxy-Authorization 用來向代理進行認證的認證信息。 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 常設
Range 僅請求某個實體的一部分。字節偏移以0開始。參見字節服務 Range: bytes=500-999 常設
Referer [sic][11] 表示瀏覽器所訪問的前一個頁面,正是那個頁面上的某個連結將瀏覽器帶到了當前所請求的這個頁面。 Referer: http://zh.wikipedia.org/wiki/Main_Page 常設
TE 瀏覽器預期接受的傳輸編碼方式:可使用回應協議頭 Transfer-Encoding 字段中的值;另外還可用"trailers"(與"分塊 "傳輸方式相關)這個值來表明瀏覽器希望在最後一個尺寸為0的塊之後還接收到一些額外的字段。 TE: trailers, deflate 常設
User-Agent 瀏覽器的瀏覽器身份標識字符串 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 常設
Upgrade 要求伺服器升級到另一個協議。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 常設
Via 向伺服器告知,這個請求是由哪些代理發出的。 Via: 1.0 fred, 1.1 example.com (Apache/1.1) 常設
Warning 一個一般性的警告,告知,在實體內容體中可能存在錯誤。 Warning: 199 Miscellaneous warning 常設

常見的非標準請求字段

字段名 說明 示例
X-Requested-With 主要用於標識 Ajax 及可擴展標記語言 請求。大部分的JavaScript框架會發送這個字段,且將其值設置為 XMLHttpRequest X-Requested-With: XMLHttpRequest
DNT[12] 請求某個網頁應用程式停止跟蹤某個用戶。在火狐瀏覽器中,相當於X-Do-Not-Track協議頭字段(自 Firefox/4.0 Beta 11 版開始支持)。SafariInternet Explorer 9 也支持這個字段。2011年3月7日,草案提交IETF。[13]萬維網協會 的跟蹤保護工作組正在就此製作一項規範。[14] DNT: 1 (DNT启用)

DNT: 0 (DNT被禁用)

X-Forwarded-For[15] 一個事實標準 ,用於標識某個通過超文本傳輸協議代理或負載均衡連接到某個網頁伺服器的客戶端的原始互聯網地址 X-Forwarded-For: client1, proxy1, proxy2

X-Forwarded-For: 129.78.138.66, 129.78.64.103

X-Forwarded-Host[16] 一個事實標準 ,用於識別客戶端原本發出的 Host 請求頭部[17] X-Forwarded-Host: zh.wikipedia.org:80

X-Forwarded-Host: zh.wikipedia.org

X-Forwarded-Proto[18] 一個事實標準,用於標識某個超文本傳輸協議請求最初所使用的協議。[19] X-Forwarded-Proto: https
Front-End-Https[20] 被微軟的伺服器和負載均衡器所使用的非標準頭部字段。 Front-End-Https: on
X-Http-Method-Override[21] 請求某個網頁應用程式使用該協議頭字段中指定的方法(一般是PUT或DELETE)來覆蓋掉在請求中所指定的方法(一般是POST)。當某個瀏覽器或防火牆阻止直接發送PUT 或DELETE 方法時(注意,這可能是因為軟件中的某個漏洞,因而需要修復,也可能是因為某個配置選項就是如此要求的,因而不應當設法繞過),可使用這種方式。 X-HTTP-Method-Override: DELETE
X-ATT-DeviceId[22] 使伺服器更容易解讀AT&T設備User-Agent字段中常見的設備型號、固件信息。 X-Att-Deviceid: GT-P7320/P7320XXLPG
X-Wap-Profile[23] 連結到互聯網上的一個XML文件,其完整、仔細地描述了正在連接的設備。右側以為AT&T Samsung Galaxy S2提供的XML文件為例。 x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml
Proxy-Connection[24] 該字段源於早期超文本傳輸協議版本實現中的錯誤。與標準的連接(Connection)字段的功能完全相同。 Proxy-Connection: keep-alive
X-Csrf-Token[25] 用於防止 跨站請求偽造。 輔助用的頭部有 X-CSRFToken[26]X-XSRF-TOKEN[27] X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

回應字段

字段名 說明 例子 狀態
Access-Control-Allow-Origin 指定哪些網站可參與到跨來源資源共享過程中 Access-Control-Allow-Origin: * 臨時
Accept-Patch[28] 指定伺服器支持的文件格式類型。 Accept-Patch: text/example;charset=utf-8 常設
Accept-Ranges 這個伺服器支持哪些種類的部分內容範圍 Accept-Ranges: bytes 常設
Age 這個對象在代理緩存中存在的時間,以秒為單位 Age: 12 常設
Allow 對於特定資源有效的動作。針對HTTP/405這一錯誤代碼而使用 Allow: GET, HEAD 常設
Cache-Control 向從伺服器直到客戶端在內的所有緩存機制告知,它們是否可以緩存這個對象。其單位為秒 Cache-Control: max-age=3600 常設
Connection 針對該連接所預期的選項

[8]

Connection: close 常設
Content-Disposition[29] 一個可以讓客戶端下載文件並建議文件名的頭部。文件名需要用雙引號包裹。 Content-Disposition: attachment; filename="fname.ext" 常設
Content-Encoding 在數據上使用的編碼類型。參考 超文本傳輸協議壓縮 。 Content-Encoding: gzip 常設
Content-Language 內容所使用的語言

[30]

Content-Language: da 常設
Content-Length 回應消息體的長度,以 字節 (8位為一字節)為單位 Content-Length: 348 常設
Content-Location 所返回的數據的一個候選位置 Content-Location: /index.htm 常設
Content-MD5 回應內容的二進制 MD5 散列,以 Base64 方式編碼 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== 過時的[9]
Content-Range 這條部分消息是屬於某條完整消息的哪個部分 Content-Range: bytes 21010-47021/47022 常設
Content-Type 當前內容的MIME類型 Content-Type: text/html; charset=utf-8 常設
Date 此條消息被發送時的日期和時間(按照 RFC 7231 中定義的「超文本傳輸協議日期」格式來表示) 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: Tue, 15 Nov 1994 12:45:26 GMT 常設
Link 用來表達與另一個資源之間的類型關係,此處所說的類型關係是在 RFC 5988 中定義的 Link: </feed>; rel="alternate"[31] 常設
Location 用來 進行重定向,或者在創建了某個新資源時使用。 Location: http://www.w3.org/pub/WWW/People.html 常設
P3P 用於支持設置P3P策略,標準格式為「P3P:CP="your_compact_policy"」。然而P3P規範並不成功,[32]大部分現代瀏覽器沒有完整實現該功能,而大量網站也將該值設為假值,從而足以用來欺騙瀏覽器的P3P插件功能並授權給第三方Cookies。 P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info." 常設
Pragma 與具體的實現相關,這些字段可能在請求/回應鏈中的任何時候產生多種效果。 Pragma: no-cache 常設
Proxy-Authenticate 要求在訪問代理時提供身份認證信息。 Proxy-Authenticate: Basic 常設
Public-Key-Pins[33] 用於緩解中間人攻擊,聲明網站認證使用的傳輸層安全協議證書的散列值 Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; 常設
Refresh 用於設定可定時的重定向跳轉。右邊例子設定了5秒後跳轉至「http://www.w3.org/pub/WWW/People.html」。 Refresh: 5; url=http://www.w3.org/pub/WWW/People.html 專利並非標準

Netscape實現的擴展,但大部分網頁瀏覽器也支持。

Retry-After 如果某個實體臨時不可用,則,此協議頭用來告知客戶端日後重試。其值可以是一個特定的時間段(以秒為單位)或一個超文本傳輸協議日期。 [34]
  • Example 1: Retry-After: 120
  • Example 2: Retry-After: Fri, 07 Nov 2014 23:59:59 GMT

常設

Server 伺服器的名字 Server: Apache/2.4.1 (Unix) 常設
HTTP cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 常設: 標準
Status 通用網關接口 協議頭字段,用來說明當前這個超文本傳輸協議回應的 狀態 。普通的超文本傳輸協議回應,會使用單獨的「狀態行」("Status-Line")作為替代,這一點是在 RFC 7230 中定義的。 [35] Status: 200 OK Not listed as a registered field name
Strict-Transport-Security HTTP 嚴格傳輸安全這一頭部告知客戶端緩存這一強制 HTTPS 策略的時間,以及這一策略是否適用於其子域名。 Strict-Transport-Security: max-age=16070400; includeSubDomains 常設: 標準
Trailer 這個頭部數值指示了在這一系列頭部信息由由分塊傳輸編碼編碼。 Trailer: Max-Forwards 常設
Transfer-Encoding 用來將實體安全地傳輸給用戶的編碼形式。當前定義的方法包括:分塊(chunked)、compress、deflate、gzip和identity。 Transfer-Encoding: chunked 常設
Upgrade 要求客戶端升級到另一個協議。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 常設
Vary 告知下游的代理伺服器,應當如何對未來的請求協議頭進行匹配,以決定是否可使用已緩存的回應內容而不是重新從原始伺服器請求新的內容。 Vary: * 常設
Via 告知代理伺服器的客戶端,當前回應是通過什麼途徑發送的。 Via: 1.0 fred, 1.1 example.com (Apache/1.1) 常設
Warning 一般性的警告,告知在實體內容體中可能存在錯誤。 Warning: 199 Miscellaneous warning 常設
WWW-Authenticate 表明在請求獲取這個實體時應當使用的認證模式。 WWW-Authenticate: Basic 常設
X-Frame-Options[36] 點擊劫持保護:
  • deny:該頁面不允許在 frame 中展示,即使是同域名內。
  • sameorigin:該頁面允許同域名內在 frame 中展示。
  • allow-from uri:該頁面允許在指定uri的 frame 中展示。
  • allowall:允許任意位置的frame顯示,非標準值。
X-Frame-Options: deny 過時的[37]

常見的非標準回應字段

字段名 說明 示例
X-XSS-Protection[38] 跨站腳本攻擊 (XSS)過濾器 X-XSS-Protection: 1; mode=block
Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP[39] 內容安全策略定義。 X-WebKit-CSP: default-src 'self'
X-Content-Type-Options[40] 唯一允許的數值為"nosniff",防止 Internet Explorer 對文件進行MIME類型嗅探。這也對 Google Chrome 下載擴展時適用。[41] X-Content-Type-Options: nosniff
X-Powered-By[42] 表明用於支持當前網頁應用程式的技術(例如:PHP)(版本號細節通常放置在 X-Runtime 或 X-Version 中) X-Powered-By: PHP/5.4.0
X-UA-Compatible[43] 推薦指定的渲染引擎(通常是向後兼容模式)來顯示內容。也用於激活 Internet Explorer 中的 Chrome Frame X-UA-Compatible: IE=EmulateIE7

X-UA-Compatible: IE=edge
X-UA-Compatible: Chrome=1

X-Content-Duration[44] 指出音視頻的長度,單位為秒。只受Gecko內核瀏覽器支持。 X-Content-Duration: 42.666
Feature-Policy 管控特定應用程式介面 Feature-Policy: vibrate 'none'; geolocation 'none'
Permissions-Policy 管控特定應用程式介面為W3C標準 替代Feature-Policy Permissions-Policy: microphone=(),geolocation=(),camera=()
X-Permitted-Cross-Domain-Policies Flash的跨網站攻擊防禦 X-Permitted-Cross-Domain-Policies: none
Referrer-Policy 保護資訊洩漏 Referrer-Policy: origin-when-cross-origin
Expect-CT 防止欺騙 SSL,單位為秒 Expect-CT: max-age=31536000, enforce

參見

參考文獻

  1. "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". ietf.org.
  2. Simtec Limited. 2. HTTP Headers. [2010-09-10]. 
  3. Internet Engineering Task Force. RFC 6648. 2012-06-01 [2012-11-12]. 
  4. Message Headers. Iana.org. 2014-06-11 [2014-06-12]. 
  5. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. itef.org. [2014-07-24]. 
  6. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. ietf.org. [2014-07-24]. 
  7. "core - Apache HTTP Server".
  8. 8.0 8.1 "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
  9. 9.0 9.1 "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
  10. "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
  11. 「引導者」(「referrer」)這個單詞,在RFC 中被拼錯了,因此在大部分的軟件實現中也拼錯了,以至於,錯誤的拼法成為了標準的用法,還被當成了正確的術語。
  12. "Try out the "Do Not Track" HTTP header" .
  13. IETF Do Not Track: A Universal Third-Party Web Tracking Opt Out March 7, 2011
  14. W3C Tracking Preference Expression (DNT) , January 26, 2012
  15. Amos Jeffries (2010-07-02).
  16. The Apache Software Foundation. "mod_proxy - Apache HTTP Server Version 2.2" .
  17. 因為反向代理往往修改這個頭部
  18. Dave Steinberg (2007-04-10).
  19. 在反向代理(負載均衡)上,即使最初發往該反向代理的請求類型是安全的超文本傳輸協議(HTTPS),該反向代理也仍然可能會使用超文本傳輸協議(HTTP)來與網頁伺服器通信。谷歌客戶端在與谷歌伺服器通信時會使用該協議頭的一個替代形式(X-ProxyUser-Ip)。
  20. "Helping to Secure Communication: Client to Front-End Server" . 2006-07-27.
  21. "OpenSocial Core API Server Specification 2.5.1" .
  22. "ATT Device ID" .
  23. "WAP Profile" .
  24. "The Proxy-Connection: header is a mistake in how some web browsers use HTTP."
  25. "SAP Cross-Site Request Forgery Protection" .
  26. "Django Cross Site Request Forgery protection" .
  27. "Angular Cross Site Request Forgery (XSRF) Protection" .
  28. "RFC 5789".
  29. "RFC 6266".
  30. https://tools.ietf.org/html/rfc7231#section-3.1.3.2(123cha<font; color: black>)</font; background-color: transparent; ; ">{{{text}}}
  31. Indicate the canonical version of a URL by responding with the Link rel="canonical" HTTP header Retrieved: 2012-02-09
  32. W3C P3P Work Suspended
  33. "Public Key Pinning Extension for HTTP" .
  34. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
  35. "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
  36. "HTTP Header Field X-Frame-Options".
  37. "Content Security Policy Level 2" .
  38. Eric Lawrence (2008-07-02).
  39. "Content Security Policy" .
  40. Eric Lawrence (2008-09-03).
  41. "Hosting - Google Chrome Extensions - Google Code" .
  42. "Why does ASP.
  43. "Defining Document Compatibility: Specifying Document Compatibility Modes" . 2011-04-01.
  44. "Configuring servers for Ogg media" . 2014-05-26.

外部連結