http header头详细说明

HTTP header字段提供有关请求或响应或消息正文中发送的对象的必需信息。HTTP消息头有四种类型：

• 通用header：这些header字段对请求和响应消息都具有通用性。

• 客户端请求header：这些header字段仅适用于请求消息。

• 服务器响应header：这些header字段仅适用于响应消息。

• 实体header：这些header字段定义有关实体主体的元信息，如果没有主体，则定义有关请求标识的资源的元信息。

通用header

Cache-Control

Cache-Control general-header字段用于指定所有缓存系统必须遵守的指令。语法如下：

Cache-Control : cache-request-directive|cache-response-directive

HTTP客户端或服务器可以使用Cache-control通用header来指定高速缓存的参数或从高速缓存中请求某些类型的文档。缓存指令在逗号分隔的列表中指定。例如：

Cache-control: no-cache

下表列出了客户端可以在其HTTP请求中使用的重要缓存请求指令：

SN	缓存请求指令和描述
1	no-cache 如果未成功与原始服务器进行重新验证，则缓存不得使用响应来满足后续请求。
2	no-store缓存不应存储有关客户端请求或服务器响应的任何内容。
3	max-age = seconds表示客户端愿意接受过期时间不超过指定时间（以秒为单位）的响应。
4	max-stale=seconds 表示客户端愿意接受超过其到期时间的响应。如果给出了秒数，则它的到期时间不得超过该时间。
5	min-fresh = seconds表示客户端愿意接受其新鲜度不少于当前时间加上指定时间（以秒为单位）的响应。
6	no-transform不转换实体主体。
7	only-if-cached不检索新数据。只有在高速缓存中时，高速缓存才能发送文档，并且不应与原始服务器联系以查看是否存在较新的副本。

服务器可以在其HTTP响应中使用以下重要的缓存响应指令：

SN	缓存响应指令和说明
1	public指示响应可以被任何缓存缓存。
2	private指示响应消息的全部或部分旨在供单个用户使用，并且不得由共享缓存缓存。
3	no-cache未经原始服务器的成功重新验证，缓存不得使用响应来满足后续请求。
4	no-store缓存不应存储有关客户端请求或服务器响应的任何内容。
5	no-transform不转换实体主体。
6	must-revalidate缓存必须在使用之前验证过时文档的状态，并且不应使用过期的文档。
7	proxy-revalidate指令与must-revalidate指令具有相同的含义，只不过它不适用于非共享的用户代理缓存。
8	max-age = seconds表示客户端愿意接受其年龄不超过指定时间（以秒为单位）的响应。
9	s-maxage = seconds该指令指定的最大年龄将覆盖max-age指令或Expires标头指定的最大年龄。专用缓存始终会忽略s-maxage指令。

Connection

连接通用header字段允许发送方指定该特定连接所需的选项，并且代理不能通过其他连接传达这些选项。以下是使用连接头的简单语法：

Connection : "Connection"

HTTP / 1.1为发送方定义了“关闭”连接选项，以指示响应完成后将关闭连接。例如：

Connection: close

默认情况下，HTTP 1.1使用持久连接，该连接在事务处理后不会自动关闭。另一方面，默认情况下，HTTP 1.0没有持久连接。如果1.0客户端希望使用持久连接，则使用keep-alive参数，如下所示：

Connection: keep-alive

日期

所有HTTP日期/时间戳都必须毫无例外地以格林威治标准时间（GMT）表示。允许HTTP应用程序使用日期/时间戳的以下三种表示形式中的任何一种：

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

在这里，第一种格式是最优选的格式。

Pragma

Pragma通用header字段用于包含特定于实现的指令，这些指令可能适用于请求/响应链中的任何接收者。例如：

Pragma: no-cache

HTTP / 1.0中定义的唯一指令是no-cache指令，并在HTTP 1.1中进行维护以实现向后兼容。将来不会定义新的Pragma指令。

传输编码

_传输编码_通用头字段指示什么变换的类型已经被应用到所述消息体，以便安全地发送者和接收者之间传送它。这与内容编码不同，因为传输编码是消息的属性，而不是实体主体的属性。Transfer-Encodingheader字段的语法如下：

Transfer-Encoding: chunked

所有传输编码值都不区分大小写。

Upgrade

该_升级_常用头允许客户指定什么额外的通信协议支持，并希望如果服务器发现是适当的交换机协议使用。例如：

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

升级header字段旨在提供一种从HTTP / 1.1过渡到其他不兼容协议的简单机制。

客户请求header

Accept

该_接受_请求头字段可以被用于指定其是用于响应上可接受的某些媒体类型。通用语法如下：

Accept: type/subtype [q=qvalue]

可以列出多个用逗号分隔的媒体类型，可选的qvalue表示可接受类型的可接受质量等级，范围为0到1。以下是一个示例：

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

这将被解释为tex /html和text/xc，它们是首选的媒体类型，但是如果它们不存在，则发送text/x-dvi实体，如果不存在，则发送text/plain实体。

Accept-Charset

_接收字符集_指示请求header字段可以被用来指示什么字符集是用于响应是可接受的。以下是一般语法：

Accept-Charset: character\_set \[q=qvalue\]

可以列出多个字符集，以逗号分隔，可选的qvalue表示非首选字符集的可接受质量等级，范围为0到1。以下是一个示例：

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

特殊值“ *”（如果存在于Accept-Charset字段中）与每个字符集匹配，并且如果不存在Accept-Charsetheader，则默认值为任何字符集都可接受。

Accept-Encoding

_接受编码_指示请求header字段内容编码。通用语法为：

Accept-Encoding: encoding types

示例如下：

Accept-Encoding:
Accept-Encoding: \*
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, \*;q=0

`Accept-Language

在_接受语言_指示请求的响应自然语言。通用语法为：

Accept-Language: language \[q=qvalue\]

可以列出多种语言，并以逗号分隔，可选的qvalue表示非首选语言的可接受质量等级，范围为0到1。以下是一个示例：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

授权书

该_授权_请求header字段值由包含被请求的用户代理的针对资源的境界认证信息凭据。通用语法为：

Authorization : credentials

HTTP / 1.0规范定义了BASIC授权方案，其中的授权参数是用base 64编码的username：password字符串。以下是一个示例：

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

该值解码为guest：guest123，其中guest是用户ID，guest123是密码。

Cookie

所述Cookie是请求header字段值中包含的名称/值对信息存储。以下是一般语法：

Cookie: name=value

可以指定多个cookie，并用分号隔开，如下所示：

Cookie: name1=value1;name2=value2;name3=value3

Host

该_主机_请求头字段用于指定Internet主机和被请求的资源的端口号。通用语法为：

Host : "Host" ":" host \[ ":" port \] ;

主机无需任何尾随端口信息意味着默认端口，这是80。例如，对于在源服务器上的请求_http://www.w3.org/pub/WWW/_将是：

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

If-Match请求头字段与方法中使用，使之条件。仅当此标记中的给定值与ETag表示的给定实体标记匹配时，此header才请求服务器执行请求的方法。通用语法为：

If-Match : entity-tag

星号（*）与任何实体匹配，并且仅当该实体存在时交易才继续。以下是可能的示例：

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

如果没有任何实体标签匹配，或者给出了“ *”并且不存在当前实体，则服务器不得执行请求的方法，并且必须返回412（失败的前提条件）响应。

Referer

Referer_请求头域允许客户端指定从该URL来请求的资源的地址（URI）。通用语法如下：

Referer : absoluteURI | relativeURI

以下是一个简单的示例：

Referer: http://www.tutorialspoint.org/http/index.htm

如果字段值是相对URI，则应相对于_Request-URI_进行解释。

User-Agent

_用户代理_请求-报头字段包含关于用户代理发起请求信息。以下是一般语法：

User-Agent : product | comment

例：

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

服务器响应头

Accept-Ranges

Accept-Ranges 响应头域允许服务器以指示其接受用于资源范围的请求。通用语法为：

Accept-Ranges : range-unit | none

例如，接受字节范围请求的服务器可以发送：

Accept-Ranges: bytes

不接受任何类型的资源范围请求的服务器可以发送：

Accept-Ranges: none

这将建议客户端不要尝试范围请求。

ETag

_ETag的_响应头域提供了所请求的变体的实体标签的当前值。通用语法为：

ETag : entity-tag

以下是一些简单的示例：

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Location

位置_响应头字段用于收件人重定向到比Request-URI中完成其他的位置。通用语法为：

Location : absoluteURI

以下是一个简单的示例：

Location: http://www.tutorialspoint.org/http/index.htm

Content-Location header字段与Location的不同之处在于Content-Location标识请求中包含的实体的原始位置。

Proxy-Authenticate

必须将_Proxy-Authenticate_响应header字段作为407（需要代理认证）响应的一部分包括在内。通用语法为：

Proxy-Authenticate : challenge

Server

该_服务器_响应头域包含关于所使用的原始服务器处理请求的软件信息。通用语法为：

Server : product | comment

以下是一个简单的示例：

Server: Apache/2.2.14 (Win32)

如果响应是通过代理转发的，则代理应用程序不得修改服务器响应头。

Set-Cookie

Set-Cookie_响应头字段包含一个名称/值对信息。通用语法为：

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie响应header包含令牌Set-Cookie，后跟一个或多个Cookie的逗号分隔列表。您可以将以下值指定为选项：

SN	选项和说明
1个	Comment=comment此选项可用于指定与cookie关联的任何注释。
2	Domain=domain域属性指定cookie对其有效的域。
3	Expires=Date-timeCookie到期的日期。如果为空，则cookie将在访问者退出浏览器时过期。
4	Path=pathPath属性指定此cookie应用于的URL的子集。
5	Secure它指示用户代理仅在安全连接下返回cookie。

例子：

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

实体标题

Allow

在_允许_实体头域列出了一组由请求URI标识的资源支持的方法。通用语法为：

Allow : Method

您可以指定多个方法，以逗号分隔。以下是一个简单的示例：

Allow: GET, HEAD, PUT

该字段不能阻止客户端尝试其他方法。

内容编码

“_内容编码_实体标题”字段用作媒体类型的修饰符。通用语法为：

Content-Encoding : content-coding

内容编码是由Request-URI标识的实体的特征。以下是一个简单的示例：

Content-Encoding: gzip

如果请求消息中实体的内容编码对于原始服务器是不可接受的，则服务器应使用状态代码415（不受支持的媒体类型）进行响应。

内容语言

_内容的语言_实体头字段描述了预期观众对于封闭实体的自然语言（S）。以下是一般语法：

Content-Language : language-tag

可能会列出针对多种受众的内容使用多种语言。以下是一个简单的示例：

Content-Language: mi, en

内容语言的主要目的是允许用户根据用户自己喜欢的语言来识别和区分实体。

内容长度

在_Content-Length的_实体头字段指示实体主体的大小，以字节为单位的十进制数，发送到接收方，或在HEAD方法的情况下，这将被发送的实体主体的大小，该请求是否为GET。通用语法为：

Content-Length : DIGITS

以下是一个简单的示例：

Content-Length: 3495

任何大于或等于零的Content-Length都是有效值。

内容位置

该_内容-位置_实体头字段可以被使用时，该实体是从所请求的资源的URI单独可访问的位置以提供用于封闭该消息中的实体资源位置。通用语法为：

Content-Location: absoluteURI | relativeURI

以下是一个简单的示例：

Content-Location: http://www.tutorialspoint.org/http/index.htm

Content-Location的值还定义了实体的基本URI。

内容MD5

所述_内容-MD5_实体头字段可以被用来提供实体的MD5摘要，用于检查该消息的在接收到的完整性。通用语法为：

Content-MD5 : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

以下是一个简单的示例：

Content-MD5 : 8c2d46911f3f5a326455f0ed7a8ed3b3

根据实体主体的内容（包括已应用的任何内容编码，但不包括应用于消息主体的任何传输编码）来计算MD5摘要。

内容范围

_内容范围_实体头域与部分实体主体发送到指定在全实体主体部分体应适用。通用语法为：

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

假设实体总共包含1234个字节，则为byte-content-range-spec值的示例：

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
  Content-Range : bytes 500-999/1234
- All except for the first 500 bytes:
  Content-Range : bytes 500-1233/1234
- The last 500 bytes:
  Content-Range : bytes 734-1233/1234

当HTTP消息包含单个范围的内容时，将使用Content-Range头和显示实际传输的字节数的Content-Length头来传输此内容。例如，

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

内容类型

_内容类型_实体头字段指示发送给接收方实体主体的媒体类型，或者在HEAD方法的情况下，这将被发送的媒体类型，有请求是一个GET。通用语法为：

Content-Type : media-type

以下是一个示例：

Content-Type: text/html; charset=ISO-8859-4

过期

_过期_实体头字段给出的日期/时间之后，响应被视为失效。通用语法为：

Expires : HTTP-date

以下是一个示例：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

最后修改

该Last-Modified_实体头字段指示原始服务器认为，变异的最后修改的日期和时间。通用语法为：

Last-Modified: HTTP-date

以下是一个示例：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT