图解HTTP-HTTP首部

1. HTTP报文首部

HTTP报文的结构

HTTP协议的请求和响应报文种必定包含HTTP首部。

首部内容为客户端和服务器分别处理请求和响应提高所需要的信息。

对于客户端用户来说，这些信息中的大部分内容都无需亲自查看。

报文首部由几个字段构成。

• HTTP请求报文

在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成。

下面的示例是访问ichistudio.cn/login时，请求报文的首部信息。

GET /login HTTP/2
Host: ichistudio.cn
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Cookie: _pk_id.1.5e6a=6407d52c24818f9f.1693809746.; wp-settings-2=libraryContent%3Dbrowse%26mfold%3Do; wp-settings-time-2=1712389118; wordpress_test_cookie=WP%20Cookie%20check; PHPSESSID=r633ocd03m7mr4svv9hppp8han; wordpress_logged_in_cc6346d3b8e19fbe3bdc85987babb589=ichi%7C1713766011%7CmSQTgnvME1Zax1kIsJkXZgSO0BelwyaiVnnJ1KvuMTi%7C8af7ae147a751a0af30c949daaa81c11845510e588c811a65b8ee577cab3c883; wfwaf-authcookie-166365dfa3fedc17559cee5fa23dd338=2%7Cadministrator%7Cmanage_options%2Cunfiltered_html%2Cedit_others_posts%2Cupload_files%2Cpublish_posts%2Cedit_posts%2Cread%7C93c33f106916190742d6d7850b10dafe4b28903fc2f113861aa54406975e84a3; wpdiscuz_nonce_cc6346d3b8e19fbe3bdc85987babb589=48538c1204
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Priority: u=1
TE: trailers

• HTTP响应报文

在响应中，HTTP报文由HTTP版本、状态码(数字和原因短语)、HTTP首部字段3部分构成。

以下示例是请求访问ichistudio.cn时，返回的响应报文的首部信息。

HTTP/2 302 
server: nginx
date: Sat, 20 Apr 2024 06:44:55 GMT
content-type: text/html; charset=UTF-8
location: https://ichistudio.cn/wp-admin/
x-redirect-by: WordPress
strict-transport-security: max-age=15768000
X-Firefox-Spdy: h2

在报文众多的字段当中，HTTP首部字段包含的信息最为丰富。

首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。

2. HTTP首部字段

2.1 HTTP首部字段传递重要信息

HTTP首部字段是构成HTTP报文的要素之一。

在客户端与服务器之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

2.2 HTTP首部字段结构

HTTP首部字段是由首部字段名和字段值构成的，中间用冒号”:”分隔。

例如，在HTTP首部中以Content-Type这个字段来表示报文主体的对象类型。

Conetent-Type:text/html

就以上述示例来看，首部字段名为Content-Type，字符串text/html是字段值。

另外，字段值对应单个HTTP首部字段可以有多个值，如下所示。

Keep-Alive:timeout=15，max=100

2.3 四种HTTP首部字段类型

HTTP首部字段根据实际用途被分为以下4种类型。

• 通用首部字段(General Header Fields)

请求报文和响应报文两方都会使用的首部。

• 请求首部字段(Request Header Fields)

从客户端向服务器端发送请求报文时使用的首部。

补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

• 响应首部字段(Response Header Fields)

从服务器端向客户端返回响应报文时使用的首部。

补充了响应的附加内容，也会要求客户端附加额外的内容信息。

• 实体首部字段(Entity Header Fields)

针对请求报文和响应报文的实体部分使用的首部。

补充了资源内容更新时间等与实体有关的信息。

2.4 HTTP/1.1首部字段一览

HTTP/1.1规范定义了如下47种首部字段。

• 通用首部字段

• 请求首部字段

• 响应首部字段

• 实体首部字段

2.5 非HTTP/1.1首部字段

在HTTP协议通信交互中使用到的首部字段，不限于RFC2616中定义的47种首部字段。

还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段，它们的使用频率也很高。

这些非正式的首部字段统一归纳在RFC4229HTTP Header Field Registrations中。

2.6 End-to-end首部和Hop-by-hop首部

HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成两种类型。

• 端到端首部(End-to-end Header)

分在此类别中的首部会转发给请求/响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。

• 逐跳首部(Hop-by-hop Header)

分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。

HTTP/1.1和之后版本中，如果要使用hop-by-hop首部，需提供Connection首部字段。

下面列举了HTTP/1.1中的逐跳首部字段。

除这8个首部字段之外，其他所有字段都属于端到端首部。

• Conection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Transfer-Encoding
• Upgrade

3. HTTP/1.1通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。

3.1 Cache-Control

通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。

指令的参数是可选的，多个指令之间通过”，”分隔。

首部字段Cache-Control的指令可用于请求及响应时。

Cache-Control:no-cache, must-revalidate, max-age=0, no-store, private

Cache-Control指令一览

可用的指令按请求和响应分类如下所示。

缓存请求指令：

缓存响应指令：

表示是否能缓存的指令

• public指令

Cache-Control:public

当指定使用public指令时，则明确表明其他用户也可用利用缓存。

• private指令

Cache-Control:private

当指定private指令后，响应只以特定的用户作为对象，这与public指令的行为相反。

缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。

• no-cache指令

Cache-Control:no-cache

使用no-cache指令的目的是为了防止从缓存中返回过期的资源。

客户端发送的请求中如果包含no-cache指令，则表示客户端将不会接收缓存过的响应。

于是，”中间”的缓存服务器必须把客户端请求转发给源服务器。

如果服务器返回的响应中包含no-cache指令，那么缓存服务器不能对资源进行缓存。

源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。

Cache-Control:no-cache=Location

由服务器返回的响应中，若报文首部字段Cache-Control中对no-cache字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不能使用缓存。

换言之，无参数值的首部字段可以使用缓存。

只能在响应指令中指定该参数。

控制可执行缓存的对象的指令

• no-store指令

Cache-Control:no-store

当使用no-store指令时，暗示请求(和对应的响应)或响应中包含机密信息。

因此，该指令规定缓存不能在本地存储请求或响应的任一部分。

指定缓存期限和认证的指令

• s-maxage指令

Cache-Control:s-maxage=604800(单位：秒)

s-maxage指令的功能和max-age指令的相同，它们的不同点是s-maxage指令只适用于供多位用户使用的公共缓存服务器。

也就是说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。

另外，当使用s-maxage指令后，则直接忽略对Expires首部字段及max-age指令的处理。

• max-age指令

Cache-Control:max-age=604800(单位：秒)

当客户端发送的请求中包含max-age指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。

另外，当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。

当服务器返回的响应中包含max-age指令时，缓存服务器将不对资源的有效性再作确认，而max-age数值代表资源保存为缓存的最长时间。

应用HTTP/1.1版本的缓存服务器遇到同时存在Expires首部字段的情况时，会优先处理max-age指令，而忽略掉Expires首部字段。

而HTTP/1.0版本的缓存服务器的情况却相反，max-age指令会被忽略掉。

• min-fresh指令

Cache-Control:min-fresh=60(单位：秒)

min-fresh指令要求缓存服务器返回至少还未过指定时间的缓存资源。

比如，当指定min-fresh为60秒后，在这60秒以内如果有超过有效期限的资源都无法作为响应返回了。

• max-stale指令

Cache-Control:max-stale=60(单位：秒)

使用max-stale可指示缓存资源，即使过期也照常接收。

如果指令未指定参数值，那么无论经过多久，客户端都会接收响应；

如果指令中指定了具体数值，那么即使过期，只要仍处于max-stale指定的时间内，仍旧会被客户端接收。

• only-if-cached指令

Cache-Control:only-if-cached

使用only-if-cached指令表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。

换言之，该指令要求缓存服务器不重新加载响应，也不会再次确认资源有效性。

若发生请求缓存服务器的本地缓存无响应，则返回状态码504Gateway Timeout。

• must-revalidate指令

Cache-Control:must-revalidate

使用must-revalidate指令，代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效。

若代理无法连通源服务器再次获取有效资源的话，缓存必须给客户端一条504(Gateway Timeout)状态码。

另外，使用must-revalidate指令会忽略请求的max-stale指令(即使已经在首部使用了max-stale，也不会再有效果)。

• proxy-revalidate指令

Cache-Control:proxy-revalidate

proxy-revalidate指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。

• no-transform指令

Cache-Control:no-transform

使用no-transform指令规定无论是在请求还是响应中，缓存都不能改变实体主体的媒体类型。

这样做可防止缓存或代理压缩图片等类似操作。

Cache-Control扩展

• cache-extension token

Cache-Control:private,community="UCI"

通过cache-extension标记(token)，可以扩展Cache-Control首部字段内的指令。

如上例，Cache-Control首部字段本身没有community这个指令。

借助extension tokens实现了该指令的添加。

如果缓存服务器不能理解community这个新指令，就会直接忽略。

因此，extension tokens仅对能理解它的缓存服务器来说是有意义的。

3.2 Connection

Connection首部字段具备如下两个作用。

• 控制不再转发给代理的首部字段
• 管理持久连接

控制代理不再转发的首部字段

Conection：不再转发的首部字段名

在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不再转发给代理的首部字段(即Hop-by-hop首部)。

管理持久连接

Connection：Close

HTTP/1.1版本的默认连接都是持久连接。

为此，客户端会在持久连接上连续发送请求。

当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。

Connection：Keep-Alive

HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。

为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定Connection首部字段的值为Keep-Alice。

3.3 Date

首部字段Date表明创建HTTP报文的日期和时间

HTTP/1.1协议使用在RFC1123中规定的日期时间的格式，如下示例

Date:Tue,03 Jul 2024 04:50:59 GMT

之前的HTTP协议版本中使用RFC850中定义的格式，如下示例

Date:Tue,03-Jul-12 04:50:59 GMT

除此之外，还有一种格式。它与C标准库内的asctime()函数的输出格式一致。

Date:Tue Jul 03 04:40:59 2024

3.4 Trailer

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。

该首部字段可应用在HTTP/1.1版本分块传输编码时。

HTTP/1.1 200 OK
Date:Tue,03 Jul 2024 04:30:30 GMT
Content-Type:text/html
Transfer-Encoding:chunked
Trailer:Expirss

......(报文主体)......
0
Expires:Tue,28 Sep 2024 06:20:30 GMT

以上用例中，指定首部字段Trailer的值为Expires，在报文主体之后(分块长度0之后)出现了首部字段Expires。

3.5 Transfer-Encoding

首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。

HTTP/1.1的传输编码方式仅对分块传输编码有效。

HTTP/1.1 200 OK
Date:Tue, 03 Jul 2024 04:30:56 GMT
Cache-Control: public,max-age=604800
Content-Type:text/javascript; charset=utf-8
Expires:Tue,10 Jul 2024 04:20:20 GMT
X-Frame-Options:DENY
X-XSS-Protection:1;mode=block
Content-Encoding:gzip
Transfer-Encoding: chunked
Connection:keep-alive

cf0  <-16进制(10进制3312)

...3312字节分块数据...

392  <-16进制(10进制为914)

...914字节分块数据...

0

以上用例中，正如在首部字段Transfer-Encoding中指定的那样，有效使用分块传输编码，且分别被分成3312字节和914字节大小的分块数据。

3.6 Upgrade

首部字段Upgrade用于检查HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

上图用例中，首部字段Upgrade指定的值为TLS/1.0。

请注意此处两个字段首部字段的对应关系，Connection的值被指定为Upgrade。

Upgrade首部字段产生作用的Upgrade对象仅限于客户端和邻接服务器之间。

因此，使用首部字段Upgrade时，还需要额外指定Connection：Upgrade。

对于附有首部字段Upgrade的请求，服务器可用101 Switching Protocols状态码作为响应返回。

3.7 Via

使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。

报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。

这个做法和tranceroute及电子邮件的Received首部的工作机制很类似。

首部字段Via不仅用于追踪报文的转发，还可避免请求回环的发生。

所以必须在经过代理时附加该首部字段内容。

上图用例中，在经过代理服务器A时，Via首部附加了”1.0gw.hackr.jp(Squid/3.1)”这样的字符串值。

行头的1.0是指接收请求的服务器上应用的HTTP协议版本。

接下来经过代理服务器B时亦是如此，在Via首部附加服务器信息，也可增加1个新的Via首部写入服务器信息。

Via首部是为了追踪传输路径，所以经常会和TRACE方法一起使用。

比如，代理服务器接收到由TRACE方法发送过来的请求(其中Max-Forwards：0)时，代理服务器就不能再转发该请求了。

这种情况下，代理服务器会将自身的信息附加到Via首部后，返回该请求的响应。

3.8 Warning

HTTP/1.1的Waring首部是从HTTP/1.0的响应首部(Retry-After)演变过来的。

该首部通常会告知用户一些与缓存相关的问题的警告。

Warning: 113 gw.hack.cn:8080 "Heuristic expiration" Tue, 30 Jul => 2024 05:15:12 GMT

Warning首部的格式如下。 最后的日期时间部分可省略。

Warning:[警告码][警告的主机：端口号]"[警告内容]"([日期时间])

HTTP/1.1 中定义了7种警告。

警告码对应的警告内容仅推荐参考。

另外，警告码具备扩展性，今后有可能追加新的警告码。

4. 请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

4.1 Accept

Accept:text/html,application/xhtml+xml,application/xml;q=0,*/*;q=0.8

Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。

可使用type/subtype这种形式，一次指定多种媒体类型。

下面我们试举几个媒体类型的例子。

• 文本文件

text/html，tetx/plain，text/css…

application/xhtml+xml，application/xml…

• 图片文件

image/jpeg，image/gif，image/png…

• 视频文件

video/mpeg，image/gif，image/png…

• 应用程序使用的二进制文件

application/octet-stream，application/zip…

比如，如果浏览器不支持PNG图片的显示，那Accept就不指定image/png，而指定可处理的image/gif和image/jpeg等图片类型。

若想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值，用分号(;)进行分隔。

权重值q的范围是0-1(可精确到小数点后3位)，且1为最大值。

不指定权重q值时，默认权重为q=1.0。

当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

4.2 Accept-Charset

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

Accept-Charset首部字段可以用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。

另外，可一次性指定多种字符集。与首部字段Accept相同的是可用权重q值来表示相对优先级。

该首部字段应用于内容协商机制的服务器驱动协商。

4.3 Accepy-Encoding

Accept-Encoding: gzip,deflate

Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。

可一次性指定多种内容编码。

下面试举出几个内容编码的例子。

• gzip

由文件压缩程序gzip(GNU zip)生成的编码格式(RFC1952)，采用Lempel-Ziv算法(LZ77)及32位循环冗余校验(CyclicRedundancy Check，通称CRC)。

• compress

由UNIX文件压缩程序compress生成的编码格式，采用Lempel-Ziv-Welch算法(LZW)

• deflate

组合使用zlib格式(RFC1950)及由deflate压缩算法(RFC1951)生成的编码格式。

• identity

不执行压缩成或不会变化的默认编码格式

采用权重q值来表示相对优先级，这点与首部字段Accept相同。

另外，也可使用星号(*)作为通配符，指定任意的编码格式。

4.4 Accept-Language

Accept-Language: zh-cn,zh; q=0.7,en-us,en; q=0.3

首部字段Accept-Language用来告知服务器用户代理能够处理的自然语言集(指中文或英文等)，以及自然语言集的相对优先级。

可一次指定多种自然语言集。

和Accept首部字段一样，按权重值q来表示相对优先级。

4.5 Authorization

Authorization:Basic dwVuweas3jahfbaj32jizx

首部字段Authorization是用来告知服务器，用户代理的认证信息(证书值)。

通常，想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Authorization加入请求中。

共用缓存在接收到含有Authorization首部字段的请求时的操作处理会略有差异。

4.6 Expect

Expect:100-continue

客户端使用首部字段Expect来告知服务器，期望出现的某种特定行为。

因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417Expectation Failed。

客户端可以利用该首部字段，写明所期望的扩展。

虽然HTTP/1.1规范只定义了100-continue。

等待状态码100响应的客户端在发生请求时，需要指定Expect:100-continue。

4.7 From

首部字段From用来告知服务器使用用户代理的用户的电子邮件地址。

通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。

使用代理时，应尽可能包含From首部字段(但可能会因代理不同，将电子邮件地址记录在User-Agent首部字段内)。

4.8 Host

Host:www.ichistudio.cn

首部字段Host会告知服务器，请求的资源所处的互联网主机名和端口号。

Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。

首部字段Host和以单台服务器分配多个域名的虚拟主机的工作制有很密切的关联，这是首部字段Host必须存在的意义。

请求被发送至服务器时，请求中的主机名会用IP地址直接替换解决。

但如果这时，相同的IP地址下部署运行着多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求。

因此，就需要使用首部字段Host来明确指出请求的主机名。

若服务器未设定主机名。那直接发送一个空值即可。

如下所示：

Host:

4.9 If-Match

形如If-xxx这种样式的请求首部字段，都可称为条件请求。

服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

形如If-xxx这种样式的请求首部字段，都可称为条件请求。

服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

首部字段If-Match，属附带条件之一，它会告知服务器匹配资源所用的实体标记(ETag)值。

这时的服务器无法使用弱ETag值。

服务器会比对If-Natch的字段值和资源的ETag值，仅当两者一致时，才会执行请求。

反之，则返回状态码412Precondition Failed的响应。

还可以使用星号(*)指定If-Match的字段值。

针对这种情况，服务器将会忽略ETag的值，只要资源存在就处理请求。

4.10 If-Modified-Since

首部字段If-None-Match属于附带条件之一。

它和首部字段If-Match作用相反。

用于指定If-None-Match字段值的实体标记(ETag)值与请求资源的ETag不一致时，它就告知服务器处理该请求。

在GET或HEAD方法中使用首部字段If-None-Match可获取最新的资源。

因此，这与使用首部字段If-Modified-Since时有些类似。

4.11 Range

Range:bytes=5001-10000

对于只需获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围。

上面的示例表示请求获取从第5001字节至第10000字节的资源。

接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206Parital Content的响应。

无法处理该范围请求时，则会返回状态码 200 OK 的响应及全部资源。

4.12 Referer

Referer:http://www.hackr.jp/index.htm

首部字段Referer会告知服务器请求的原始资源的URI。

客户端一般都会发送Referer首部字段给服务器。

但当直接在浏览器的地址栏输入URI，或出于安全性的考虑时，也可以不发送该首部字段。

因为原始资源的URI中的查询字符串可能含有ID和密码等保密信息，要是写进Referer转发的其他服务器，则有可能导致保密信息的泄漏。

4.13 TE

TE: gzip, deflate; q=0.5

首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相对优先级。

它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。

首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分块传输编码的方式。

应用后者时，只需把tranilers赋值给该字段值。

TE:trailere

4.14 User-Agent

User-Agent:Mozilla/5.0(Window NT 6.1;WOW64;rv:13.0) Gecko/=>20100101 Firefox/13.0.1

首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。

由网络爬虫发起请求时，有可能会在字段内添加爬虫作者的电子邮箱地址。

此外，如果请求经过代理，那么中间也很可能被添加上代理服务器的名称。

5. 响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

5.1 Accept-Ranges

Accept-Ranges:bytes

首部字段Accept-Ranges是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。

可指定的字段值有两种，可处理范围请求时指定其为bytes，反之则指定其为none。

5.2 Age

Age:600

首部字段Age能告知客户端，源服务器在多久前创建了响应。

字段值的单位为秒。

若创建该响应的服务器缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。

5.3 Location

Location:http://www.usagidesign.cn/sample.html

使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。

基本上，该字段会配合3XX：Redirection的响应，提供重定向的URI。

几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。

5.4 Proxy-Authenticate

Proxy-Authenticate:Basic realm="Usagidesign Auth"

首部字段Proxy-Authenticate会把代理服务器所要求的认证信息发送给客户端。

它与客户端和服务器之间的HTTP访问认证的行为相似，不同之处在于其认证行为是在客户端与代理之间进行的。

而客户端与服务器之间进行认证时，首部字段WWW-Authorization有着相同的作用。

5.5 Retry-After

Retry-After:120

首部字段Retry-After告知客户端应该在多久之后再次发送请求。

主要配合状态码503 Servcie Unavailable响应，或3xx Redirect响应一起使用。

字段值可以指定为具体的日期时间(Wed,04 Jul 2012 06:34:24 GMT等格式)，也可以是创建响应后的秒数。

5.6 Server

Server:Apache/2.2.17(Unix)

首部字段Server告知客户端当前服务器上安装的HTTP服务器应用程序的信息。

不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。

Server:Apache/2.2.6(Unix) PHP/5.2.5

5.6 WWW-Authenticate

WWW-Authenicate: Basic realm="Usagidesign Auth"

首部字段WWW-Authenticate 用于HTTP访问认证。

它会告知客户端适用于访问请求URI所指定指定资源的认证方案(Basic或是Digest)和带参数提示的质询(challenge)。

状态码401 Unauthorized响应中，肯定带有首部字段WWW-Authenticate。

6. 实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

6.1 Allow

Allow:GET,HEAD

首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。

当服务器接收到不支持的HTTP方法时，会以状态码405Method Not Allowed作为响应返回。

与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。

6.2 Content-Encoding

首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容编码方式。

内容编码是指在不丢失实体信息的前提下所进行的压缩。

主要采用以下4种内容编码的方式。

• gzip
• compress
• deflate
• identity

6.3 Content-Language

Content-Language:zh-CN

首部字段Content-Language会告知客户端，实体主体使用的自然语言(指中文或英文等语言)。

6.4 Content-Length

Content-Length:15000

首部字段Content-Length表明了实体主体部分的大小(单位是字节)。

对实体主体进行内容编码传输时，不能再使用Content-Length首部字段。

由于实体主体大小的计算方式略微复杂，所以在此不再展开。

6.5 Content-Location

Content-Location:http://www.hackr.cn/index.js.html

首部字段Content-Location给出与报文主体部分相对应的URI。

和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。

比如，对于使用首部字段Accept-Language的服务器驱动型请求，当返回的页面内容与实际请求的对象不同时，首部字段Content-Location内会写明URI。

6.6 Content-MD5

Content-MD5:ADASDJLDJLDHLASJHJQWEHUIBNIDBAJ==

首部字段Content-MD5是一串由MD5算法生成的值。

其目的在于检测报文主体在传输过程种是否保持完整，以及确认传输到达。

对报文主体执行MD5算法获得的128位二进制数，再通过Base64编码后将结果写入Content-MD5字段值。

为确保报文的有效性，作为接收方的客户端会对报文主体再执行一次相同的MD5算法。

计算出的值与字段值作比较后，即可判断出报文主体的准确性。

采用这种方法，对内容上的偶发性改变是无从查证的，也无法检测出恶意篡改。

其中一个原因在于，内容如果能够被篡改，那么同时意外着Content-MD5也可重新计算然后被篡改。

所以处在接收阶段的客户端是无法意识到报文主体以及首部字段Content-MD5是已经被篡改过的。

6.7 Content-Range

Content-Range:bytes 5001-10000/10000

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。

字段值以字节为单位，表示当前发送部分及整个实体大小。

6.8 Content-Type

Content-Type:text/html; charset-UTF-8

首部字段Conten-Type说明了实体主体内对象的媒体类型。

和首部字段Accept一样，字段值用type/subtype形式赋值。

参数charset使用iso-8859-1或euc-cn等字符集进行赋值。

Expires: Wed，04 Jul 2024 08:26 GMT

首部字段Expires会将资源失效的日期告知客户端。

缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。

当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

源服务器不希望缓存服务器对资源缓存时，最好在Expires字段内写入与首部字段Date相同的时间值。

但是，当首部字段Cache-Control有指定max-age指令时，比起首部字段Expires，会优先处理max-age指令。

6.10 Last-Modified

Last-Modified:Wed，23 May 2024 09:59:30 GMT

首部字段Last-Modified指明资源最终修改的时间。

一般来说，这个值就是Request-URI指定资源被修改的时间。

但类似使用CGI脚本进行动态数据处理时，该值有可能会变成数据最终修改时的时间。

7. 为Cookie服务的首部字段

管理服务器与客户端之间状态的Cookie，虽然没有被编入标准化HTTP/1.1的RFC2616中，但在Web网站方面得到了广泛的应用。

Cookie的工作机制是用户识别及状态管理。

Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内。

接着当用户访问该Web网站时，可通过通信方式取回之前存放的Cookie。

调用Cookie时，由于可校验Cookie的有效期，以及发送方的域、路径、协议等信息，所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄漏。

至今，Cookie的规格标准文档有以下四种：

• 由网景公司颁布的规格标准：网景通信公司设计并开发了Cookie，并制定了相关的规格标准。
• RFC2109：某企业尝试以独立技术对Cookie规格进行标准化统筹。
• RFC2965：为终结IE浏览器与Netscape标准差异而导致的浏览器战争，RFC2965内定义了新的HTTP首部Set-Cookie2和Cookie2。
• RFC6265：将网景公司制定的标准作为业界事实标准，重新定义Cookie标准后的产物。

目前使用最广泛的Cookie标准却不是RFC中定义的任何一个。

而是在网景公司制定的标准上进行扩展后的产物。

7.1 Set-Cookie

Set-Cookie:status=enable; expires=Tue, 05 Jul 2024 09:26:31 GMT; =>path=/; domain=.hack.cn

当服务器准备开始管理客户端的状态时，会事先告知各种信息。

下面的表格列举了Set-Cookie的字段值

expires属性

Cookie的expirex属性指定浏览器可发送Cookie的有效期。

当省略expires属性时，其有效期仅限于维持浏览器会话(Session)时间段内。

这通常限于浏览器应用程序被关闭之前。

另外，一旦Cookie从服务器端发送至客户端，服务器端就不存在可以显式删除Cookie的方法。

但可通过覆盖已过期的Cookie，实现对客户端Cookie的实质性删除操作。

path属性

Cookie的path属性可用于限制指定Cookie的发送范围的文件目录。

不过另有办法可避开这项限制，看来对其作为安全机制的效果不能抱有期待。

domain属性

通过Cookie的domain属性指定的域名可做到与结尾匹配一致。

比如，当指定example.com后，除example.com以外，www.example.com或www2.example.com等都可用发送Cookie。

因此，除了针对具体指定的多个域名发送Cookie之外，不指定domain属性显得更安全。

secure属性

Cookie的secure属性用于限制Web页面仅在HTTPS安全连接时，才可以发送Cookie。

发送Cookie时，指定secure属性的方法如下所示。

Set-Cookie:name=value; secure

以上例子仅当在https:www.example.com/(HTTPS)安全连接的情况下才会进行Cookie的回收。

也就是说，即使域名相同，http://www.example.com(HTTP)也不会发送Cookie回收行为。

当省略secure属性时，不论HTTP还是HTTPS，都会对Cookie进行回收。

HttpOnly属性

Cookie的HttpOnly属性是Cookie的扩展功能，它使JavaScript脚本无法获得Cookie。

其主要目的为防止跨站脚本攻击(Cross-site scripting，XSS)对Cookie的信息窃取。

发送指定HttpOnly属性的Cookie的方法如下：

Set-Cookie:name=value; HttpOnly

通过上述设置，通常从Web页面内还可以对Cookie进行读取操作。

但使用JavaScript的doucument.cookie就无法读取附加HttpOnly属性后的Cookie的内容了。

因此，也就无法在XSS中利用JavaScript劫持Cookie了。

7.2 Cookie

Cookie:status=enable

首部字段Cookie会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。

接收到多个Cookie时，同样可以以多个Cookie形式发送。

8. 其他首部字段

HTTP首部字段是可以自行扩展的。

所以在Web服务器和浏览器的应用上，会出现各种非标准的首部字段。

接下来，我们就一些最为常用的首部字段进行说明。

• X-Frame-Options
• X-XSS-Protection
• DNT
• P3P

8.1 X-Frame-Options

X-Frame-Options:DENY

首部字段X-Frame-Options属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的显式问题。

其主要目的是为了防止点击劫持(clickjacking)攻击。

首部字段X-Frame-Options有以下两个可指定的字段值。

• DENY：拒绝
• SAMEORIGIN：仅同源域名下的页面(Top-level-browsing-context)匹配时许可。

现在主流的浏览器都已经支持。

能在所有的Web服务器端预先设定好X-Frame-Options字段值是最理想的状态。

8.2 X-XSS-Protection

X-XSS-Protection:1

首部字段X-XSS-Protection属于HTTP响应首部，它是针对跨站脚本攻击(XSS)的一种对策，用于控制浏览器XSS防护机制的开关。

首部字段X-XSS-Protection可指定的字段值如下：

• 0：将XSS过滤设置成无效状态
• 1：将XSS过滤设置成有效状态

8.3 DNT

DNT:1

首部字段DNT属于HTTP请求首部，其中DNT是Do Not Track的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。

首部字段DNT可指定的字段值如下：

• 0：同意被追踪
• 1：拒绝被追踪

由于首部字段DNT的功能具备有效性，所以Web服务器需要对DNT做对应的支持。

8.4 P3P

P3P:CP="CAO DSP LAW CURa ADMa DEVa PSAa PSDa" =>
IVAa IVDa OUR BUS IND UNI COM NAV INT"

首部字段P3P属于HTTP响应首部，通过利用P3P(The Plateform for Privacy Preferences，在线隐私偏好平台)技术，可以让Web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

要进行P3P的设定，需按以下操作步骤进行。

• 步骤1：创建P3P隐私
• 步骤2：创建P3P隐私对照文件后，保存命名在/w3c/p3p.xml
• 步骤3：从P3P隐私中新建Compact policies后，输出到HTTP响应中