HTTP - 首部
首部类型
| 首部类型 | 说明 |
| 通用首部 | 客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些有用的通用首部。 |
| 请求首部 | 请求首部时请求报文特有的。它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据。 |
| 响应首部 | 响应报文有自己的首部集，以便为客户端提供信息。 |
| 实体首部 | 实体首部指的是应对实体主体部分的首部。比如，可以用实体首部来说明实体主体部分的数据类型。 |
| 扩展首部 | 扩展首部是非标准的首部，由应用程序开发者创建，但还未添加到已批准的 HTTP 规范中去。既使不知道这些扩展首部的含义，HTTP 程序也要接受它们并对其进行转发。 |
首部详细说明
Accept
客户端用 Accept 首部来通知服务器可以接受哪些媒体类型。Accept 首部字段的值是客户端可以使用的媒体类型列表。如果 Web 浏览器无法显示 Web 上所有的多媒体对象类型，就可以再请求中包含 Accept 首部，这样浏览器就不会去下载它无法使用的视频或其他对象类型了。
类型 请求首部
注释 “*” 是个特殊值用来通配媒体类型。比如，“*/*” 表示所有类型，“image/*” 表示所有的图片类型。
举例 Accept: text/css,*/*;q=0.1
Accept-Charset
客户端用 Accept-Charset 首部来通知服务器它可以接受哪些字符集或哪些是优先字符集。这个请求首部的值是个字符集列表和所列字符集可能的质量值。当服务器上有多种可以接受字符集表示的文档时，可以通过质量值告知服务器哪个字符集是优先的。
类型 请求首部
基本语法 Accept-Charset: 1 # ((charset | "*") [";" "q " "=" qvalue])
举例 Accept-Charset: utf-8
Accept-Encoding
客户端用 Accept-Encoding 首部来告知服务器它可以接受哪些编码方式。
类型 请求首部
基本语法 Accept-Encoding: 1# (( content-coding | "*" ) [ ";" "q" "=" qvalue ] )
举例 Accept-Encoding: gzip, deflate, sdch
Accept-Language
客户端用 Accept-Language 请求首部通知服务器可接受或优选哪些语言。
类型 请求首部
举例 Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Accept-Ranges
Accept-Ranges 首部与其他的 Accept 首部不同——它是服务器使用的一种响应首部，用来告知客户端它们是否接受请求资源的某个范围。如果这个首部有赋值的话，这个值就说明了服务器允许对指定资源的哪个范围类型进行访问。
类型 响应首部
基本语法 Accept-Ranges: 1# range-unit | none
举例 Accept-Ranges: bytes
Age
Age 首部可以告诉接收端响应已产生了多长时间。对于原始服务器是在多久之前产生的响应或是在多久之前向原始服务器再次验证响应而言，这是发送端所做的最好的猜测。首部的值是发送端所做的猜测，以秒为单位递增。
类型 响应首部
注释 HTTP/1.1 缓存必须在发送的每条响应中都包含一个 Age 首部。
基本语法 Age: delta-seconds
举例 Age: 40
Allow
Allow 首部用于通知客户端可以对特定资源使用哪些 HTTP 方法。
类型 响应首部
注释 发送 405 Method Not Allowed 响应的 HTTP/1.1 服务器必须包含 Allow 首部。
基本语法 Allow: #Method
举例 Allow: GET, HEAD
Authorization
Authorization 首部时由客户端发送的，用来向服务器回应自己的身份验证信息。客户端收到来自服务器的 401 Authorization Required 响应后，要在其请求中包含这个首部。这个首部的值取决于所使用的认证方案。
类型 请求首部
基本语法 Authorization: authentication-schema #authentication-param
举例 Authorization: Basic YnJpYW4tdG90dHk6T3ch
Cache-Control
Cache-Control 首部用于传输对象的缓存信息。这个首部是 HTTP/1.1 引入的比较复杂的首部之一。它的值是一个缓存指令，给出了与某个对象可缓存性有关的缓存特有指令。
类型 通用首部
举例 Cache-Control: must-revalidate, no-cache, private
Client-ip
Client-ip 首部是一些比较老的客户端和代理使用的扩展首部，用来传输运行客户端程序的计算机 IP 地址。
类型 扩展请求首部
基本语法 Client-ip: ip-address
举例 Client-ip: 209.1.33.49
Connection
Connection 首部允许客户端和服务器指定与请求/响应连接有关的选项
类型 通用首部
基本语法 Connection: 1# (connection-token)
举例 Connection: keep-alive
Content-Base
服务器可以通过 Content-Base 首部为响应主体部分中要解析的 URL 指定一个基础 URL。Content-Base 首部的值是一个绝对 URL，可以用来解析在实体内找到的相对 URL。RFC 2616 中没有定义 Content-Base 首部。它是早期在 RFC 2068 中定义的，RFC 2068 是一个较早的 HTTP/1.1 规范草案，已经从官方规范中删除了。
类型 实体首部
基本语法 Content-Base: absoluteURL
举例 Content-Base: http://www.example.com/
Content-Encoding
Content-Encoding 首部用于说明是否对某对象进行编码。通过对内容进行编码服务器可以再发送响应之前将其进行压缩。Content-Encoding 首部的值可以告诉客户端，服务器对对象执行过哪种或哪些类型的编码。有了这个信息，客户端就可以对报文进行解码了。有时服务器会对某个实体进行多种编码，在这种情况下，必须按照执行的顺序将编码列出。
类型 实体首部
基本语法 Content-Encoding: 1# content-coding
举例 Content-Encoding: gzip
Content-Language
Content-Language 首部用来告诉想要理解对象的客户端，应该理解哪种自然语言。比如说，一篇用法语编写的文档就应该有一个表示法语的 Content-Language 值。如果在响应中没有提供这个值，对象就是提供给所有用户的。首部值中有多少种语言就说明对象适用于所列各种语言的用户。
类型 实体首部
基本语法 Content-Language: 1# language-tag
举例 Content-Language: en
Content-Length
Content-Length 首部说明实体主体部分的长度或尺寸。
类型 实体首部
基本语法 Content-Length: 1*DIGIT
举例 Content-Length: 2672
Content-Location
Content-Location 首部包含在一个 HTTP 报文中，给出了与报文的实体部分相对应的 URL。对可能有多个 URL 的对象来说，响应报文中可以包含一个 Content-Location 首部，说明用来产生响应的对象的 URL。Content-Location 可以与所请求的 URL 不同。服务器通常会用它将客户端导向或重定向到一个新 URL 上去。如果 URL 是相对的，就应该相对于 Content-Base 首部加以解释。如果没有提供 Content-Base 首部，就应该使用请求中的 URL。
类型 实体首部
基本语法 Content-Location: (absoluteURL | relativeURL)
举例 Content-Location: http://example.com/index.html
Content-MD5
Content-MD5 首部是服务器用来对报文主体进行报文完整性检查的。只有原始服务器或发起请求的客户端可以在报文中插入 Content-MD5 首部。根据 RFC 1864 的定义，MD5 摘要值是一个 Base-64 或 128 位的 MD5 摘要
类型 实体首部
基本语法 Content-MD5: md5-digest
举例 Content-MD5: Q2h1Y2sgSW51ZwDIAXR5IQ==
Content-Range
请求传输某范围内的文档时，产生的结果由 Content-Range 首部给出。它提供了请求实体所在的原始实体内的位置（范围），还给出了整个实体的长度。如果值为 “*”，而不是整个实体的长度，就表示发送响应时，长度未知。
类型 实体首部
举例 Content-Range: bytes 500-999 / 5400
Content-Type
Content-Type 首部说明了报文中对象的媒体类型。
类型 实体首部
基本语法 Content-Type: media-type
举例 Content-Type: text/html; charset=iso-8859-1
Cookie
Cookie 首部是用于客户端识别和跟踪的扩展首部。
类型 扩展请求首部
举例 Cookie: csrftoken=TDSYg9AbMT1Ae3vKP2Uvqqwgw9LjBsyW
Cookie2
Cookie2 首部是用于客户端识别和跟踪的扩展首部。Cookie2 用于识别请求发起者能够理解哪些类型的 Cookie。
类型 扩展请求首部
举例 Cookie: $version="1"
Date
Date 首部给出了报文创建的日期和时间。服务器响应中要包含这个首部，因为缓存在评估响应的新鲜度时，要用到这个服务器认定的报文创建时间和日期。对客户端来说，这个首部时可选的，但包含这个首部会更好。
类型 通用首部
基本语法 Date: HTTP-date
举例 Date: Sat, 09 May 2015 02:59:04 GMT
ETag
ETag 首部为报文中包含的实体提供了实体标记。实体标记是一种标识资源的方式。
类型 实体首部
基本语法 ETag: entity-tag
举例 ETag: "FuUGTtRWVl1Vu7X8i_XlPWpCSttV.gz"
Expect
客户端通过 Expect 首部告知服务器它们需求某种行为。如果服务器无法理解 Expect 首部的值，就应该以状态码 417 Expection Failed 进行响应。
类型 请求首部
基本语法 Expect: 1# ("100-continue" | expectation-extension)
举例 Expect: 100-continue
Expires
Expires 首部给出了响应失效的日期和时间。这样，像浏览器这样的客户端就可以缓存一份副本，在这个时间到期之前，不用去询问服务器它是否有效了。
类型 实体首部
基本语法 Expires: HTTP-date
举例 Expires: Mon, 11 May 2015 05:06:18 GMT
From
From 首部说明请求来自何方。其格式就是（RFC 1123 规定的）客户端用户的有效电子邮件地址。
类型 请求首部
基本语法 From: mailbox
举例 From: slurp@inktomi.com
Host
客户端通过 Host 首部为服务器提供客户端想要访问的那台机器的因特网主机名和端口号。
类型 请求首部
注释 HTTP/1.1 客户端必须在所有请求中包含 Host 首部。所有的 HTTP/1.1 服务器都必须以 400 Bad Request 状态码去响应没有提供 Host 首部的客户端。
基本语法 Host: host [":" port]
举例 Host:www.example.com
If-Modified-Since
If-Modified-Since 请求首部用来发起条件请求。客户端可以用 GET 方法去请求服务器上的资源，而响应则取决于客户端上次请求此资源之后，该资源是否修改过。如果对象未被修改过，服务器会回送一条 304 Not Modified 响应，而不会回送此资源。如果对象被修改过，服务器就会像对待非条件 GET 请求一样响应。
类型 请求首部
基本语法 If-Modified-Since: HTTP-date
举例 If-Modified-Since: Mon, 11 May 2015 05:06:18 GMT
If-Match
与 If-Modified-Since 首部类似，If-Match 首部也可以用于发起条件请求。If-Match 请求使用的是实体标记，而不是日期。服务器将对比 If-Match 首部的实体标记与资源当前的实体标记，如果标记匹配，就将对象返回。服务器应该用 If-Match 值 “*” 与某资源拥有的所有实体标记进行匹配。除非服务器上没有这个资源了，否则 “*” 总会与实体标记相匹配。
类型 请求首部
基本语法 If-Match: ("*" | 1# entity-tag)
举例 If-Match: "11e92a-457b-31345aa"
If-None-Match
与所有 If 首部一样，If-None-Match 首部可以用于发起条件请求。客户端为服务器提供一个实体标记列表，服务器将这些标记与它拥有的资源实体标记进行比较，只在都不匹配的时候才将资源返回。这样缓存就可以只在资源已被修改的情况下才更新。通过 If-None-Match 首部，缓存可以用一条请求使它拥有的实体失效，同时在响应中接收新的实体。
类型 请求首部
基本语法 If-None-Match: ("*" | 1# entity-tag)
举例 If-None-Match: "11e92a-457b-31345aa"
If-Range
与所有 If 首部一样，If-Range 首部可以用于发起条件请求。应用程序拥有某范围内资源的副本，它要对范围进行再验证，如果范围无效的话，要获取新的资源，在这种情况下会使用这个首部。
类型 请求首部
基本语法 If-Range: (HTTP-date | entity-tag)
举例 If-Range: "11e92a-457b-31345aa"
If-Unmodified-Since
If-Unmodified-Since 和 If-Modified-Since 首部是一对“双胞胎”。在请求中包含此首部就可以发起条件请求。服务器应该去查看首部的日期值，只有在从首部提供的日期之后，对象都未被修改过，才会返回对象。
类型 请求首部
基本语法 If-Unmodified-Since: HTTP-date
举例 If-Unmodified-Since: Mon, 11 May 2015 05:06:18 GMT
Last-Modified
Last-Modified 首部试图提供这个实体最后一次被修改的相关信息。这个值可以说明很多事情。比如，资源通常都是一台服务器上的文件，因此 Last-Modified 值可能就是服务器的文件系统所提供的最后修改时间。另一方面，对于那些动态创建的资源，Last-Modified 值可能就是创建响应的实际时间。服务器要注意，Last-Modified 时间不应该是未来时间。如果它比 Date 首部中要发送的值还迟，HTTP/1.1 服务器就会将 Last-Modified 时间重置。
类型 请求首部
基本语法 Last-Modified: HTTP-date
举例 Last-Modified: Mon, 11 May 2015 05:06:18 GMT
Location
服务器可以通过 Location 首部将客户端导向某个资源的地址，这个资源可能在客户端最后一次请求之后被移动过，也可能是在对请求的响应中创建的。
类型 响应首部
基本语法 Location: absoluteURL
举例 Location: http://www.sina.com.cn/
Max-Forwards
这个首部只能和 TRACE 方法一同使用，以指定请求所经过的代理或其他中间节点的最大数目。它的值是个整数。所有收到带此首部的 TRACE 请求的应用程序，在将请求转发出去之前都要将这个值减 1。如果应用程序收到请求时，这个首部的值为零，就要向请求回应一条 200 OK 响应，并在实体的主体部分包含原始请求。如果 TRACE 请求中没有 Max-Forwards 首部，就假定没有转发最大次数的限制。其他 HTTP 方法都应该忽略这个首部。
类型 请求首部
基本语法 Max-Forwards: 1*DIGIT
举例 Max-Forwards: 5
Pragma
Pragma 首部用于随报文传送一些指令。这些指令几乎可以包含任何内容，但通常会用这些指令来控制缓存的行为。Pragma 首部的目标可以是接收这条报文的所有应用程序，因此代理和网关一定不能将其删除。最常见的 Pragma 形式 —— Pragma: no-cache 是一个请求首部，通过它可以迫使缓存在有新鲜副本可用的情况下，向原始服务器请求文档或对其进行再验证。用户点击重新加载 / 刷新按钮时，浏览器就会发出这个首部。很多服务器会将 Pragma: no-cache 作为响应首部发送（和 Cache-Control: no-cache 等价）。尽管这个首部得到了广泛的使用，但从技术上来说，并没有定义过其行为，不是所有的应用程序都支持 Pragma 响应首部。
类型 请求首部
基本语法 请求首部
举例 Pragma: no-cache
Proxy-Authenticate
Proxy-Authenticate 首部的功能类似于 WWW-Authenticate 首部。代理会使用这个来质询发送请求的应用程序，要求其对自身进行认证。如果一台 HTTP/1.1 代理服务器发送了一条 407 Proxy Authentication Required 响应，就必须包含 Proxy-Authenticate 首部。代理和网关在解析所有的 Proxy 首部时都要特别小心。通常它们都是逐跳首部，只适用于当前的连接。比如，Proxy-Authenticate 首部会要求对当前的连接进行认证。
类型 响应首部
基本语法 Proxy-Authenticate: challenge
举例 Proxy-Authenticate: Basic realm="Super Secret Corporate FinancialDocuments"
Proxy-Authorization
Proxy-Authorization 首部的功能与 Authorization 首部类似。客户端应用程序可以用它来响应 Proxy-Authenticate 质询。
类型 请求首部
基本语法 Proxy-Authorization: credentials
举例 Proxy-Authorization: Basic YnJpYW4tdG90dHk6T3ch
Proxy-Connection
Proxy-Connection 首部的语义与 HTTP/1.0 Connection 首部类似。在客户端和代理之间可以用它来指定与连接（主要是 keep-alive 连接）有关的选项。它并不是一个标准的首部，标准委员会把它当作一个临时首部。但它得到了浏览器和代理的广泛使用。浏览器实现者创建了 Proxy-Connection 首部，来解决客户端发送的HTTP/1.0 Connection 首部被哑代理盲转发的问题。
类型 通用首部
基本语法 Proxy-Connection: 1# (connection-token)
举例 Proxy-Connection: close
Public
服务器可以用 Public 首部告知客户端它支持哪些方法。
类型 响应首部
注释 RFC 2616 中没有雨定义这个首部。它是之前在 HTTP/1.1 规范的早期草案 RFC 2068 中定义的，而官方规范已经将其删除了。
基本语法 Public： 1# HTTP-method
举例 Public: OPTIONS, GET, HEAD, TRACE, POST
Range
在请求某实体的部分内容会用到 Range 首部。它的值说明了报文所包含实体的范围。请求某范围内的文档可以更有效地对大型对象发出请求（分段对其发出请求），或者更有效地从传输错误中恢复（允许客户端请求没有完成的那部分资源）。
类型 实体首部
举例 Range: bytes=500-1500
Referer
在客户端请求中插入 Referer 首部，可以使服务器知道客户端是从哪里获得其请求的 URL。这是一种对服务器有益的自愿行为，这样服务器就可以更好地记录请求，或者执行其他任务了。
类型 请求首部
基本语法 Referer: (absoluteURL | relativeURL)
举例 Referer: http://www.example.com/
Retry-After
服务器可以用 Retry-After 首部告知客户端什么时候重新发送某资源的请求。这个首部可以与 503 Service Unavailable 状态码配合使用，给出客户端可以重试其请求的具体日期和时间（或者秒数）。
类型 响应首部
基本语法 Retry-After: (HTTP-date | delta-seconds)
举例 Retry-After: Mon, 11 May 2015 05:06:18 GMT
Server
Server 首部是用来识别服务器软件的，而且包含了与软件有关的附近注释，所以其格式比较随意。
类型 响应首部
基本语法 Server: 1* (product | comment)
举例 Server: Apache-Coyote/1.1
Set-Cookie
Set-Cookie 首部
类型 扩展响应首部是 Cookie 首部的搭档。
基本语法 Set-Cookie: command
举例 Set-Cookie: userid=2480695; Path=/
Set-Cookie2
Set-Cookie 首部是对 Set-Cookie 首部的扩展。
类型 扩展响应首部
基本语法 Set-Cookie2: command
举例 Set-Cookie: ID="2480695"; Domain=".example.com"
TE
TE 首部的功能与 Accept-Encoding 首部类似，但它是用于传输编码的。TE 首部还可以用来说明客户端能否处理位于分块编码的响应拖挂中的首部。
类型 请求首部
基本语法 TE: # (transfer-coding)
举例 TE: chunked
Trailer
Trailer 首部用于说明报文拖挂中提供了哪些首部。
类型 通用首部
基本语法 Trailer: 1# field-name
举例 Trailer: Content-Length
Transfer-Encoding
如果要通过某些编码来安全地传送 HTTP 报文主体，报文中就要包含 Transfer-Encoding 首部。它的值是一个对报文主体执行过编码的列表。如果进行了多种编码，就将其按序排列。Transfer-Encoding 首部与 Content-Encoding 首部不同，因为服务器或其他中间应用程序是通过执行 Transfer-Encoding 对要传输的报文进行编码的。
类型 通用首部
基本语法 Transfer-Encoding: 1 # transfer-coding
举例 Transfer-Encoding: chunked
Upgrade
Upgrade 首部为报文发送者提供了一种手段，使其指定另一种可能完全不同协议并将此意愿向外广播。比如，HTTP/1.1 客户端可以向服务器发送一条 HTTP/1.0 请求，其中包含了值为 “HTTP/1.1” 的 Upgrade 首部，这样客户端就可以测试一下服务器是否也使用 HTTP/1.1 了。如果服务器也可以使用 HTTP/1.1，就可以发送一条适当的响应，让客户端知道可以使用新的协议。这样就提供了一种切换使用其他协议的有效方式。现在大部分服务器都只兼容 HTTP/1.0，通过这种策略，在判定服务器确实能够使用 HTTP/1.1 之前，客户端就会用很多的 HTTP/1.1 首部骚扰服务器了。服务器发送 101 Switching Protocols 响应时，必须包含这个首部。
类型 通用首部
基本语法 Upgrade: 1# protocol
举例 Upgrade: HTTP/1.1
User-Agent
客户端应用程序通过 User-Agent 首部来标识其类型，与服务器的 Server 首部类似。
类型 请求首部
基本语法 User-Agent: 1* (product | comment)
举例 User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
Vary
服务器通过 Vary 首部来通知客户端，在服务器端的协议会使用哪些来自客户端的请求首部。它的值是一个首部列表，服务器会去查看这些首部，以确定将什么内容作为响应发回给客户端。报文在向客户端或服务器传输的途径中经过某个 HTTP 应用程序时，这个应用程序可以通过 Via 首部对通过它的报文进行标记。
类型 响应首部
基本语法 Vary: ("*" | 1# field-name)
举例 Vary: Accept-Encoding
Via
Via 首部用于在报文经过代理和网关时对其进行跟踪。
类型 通用首部
基本语法 Via: 1# (received-protocol received-by [comment])
举例 Via: 1.1 varnish
WWW-Authenticate
WWW-Authenticate 首部用于 401 Unauthorized 响应，向客户端发布一个质询认证方案。
类型 响应首部
基本语法 WWW-Authenticate: 1# challenge
举例 WWW-Authenticate: Basic realm="Your private Travel Profile"
