图解HTTP(六)—— HTTP请求头(首部)

一、HTTP报文首部

        HTTP协议的请求和响应报文中必定包含HTTP报文首部。首部内容分别为客户端和服务器处理请求和响应提供所需要的信息。

1、HTTP请求报文

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

2、HTTP响应报文

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

3、请求和响应HTTP报文示例

图解HTTP(六)—— HTTP请求头(首部)_第1张图片

二、HTTP首部字段

        HTTP首部字段是构成HTTP报文的要素之一,它可以给浏览器、服务器提供报文主体大小、所使用的语言、认证信息等。

1、HTTP首部字段结构

HTTP首部字段是由字段名和字段值构成,中间用冒号(:)分隔,如下:

Content-Type:text/html

单个HTTP首部字段可以有多个值,用逗号(,)分隔,如下:

Keep-Alive:timeout=15,max=100

2、HTTP首部字段类型

① 通用首部字段

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

② 请求首部字段

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

③ 响应首部字段

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

④ 实体首部字段

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

3、HTTP首部字段一览

通用首部字段

图解HTTP(六)—— HTTP请求头(首部)_第2张图片

请求首部字段

图解HTTP(六)—— HTTP请求头(首部)_第3张图片

响应首部字段

图解HTTP(六)—— HTTP请求头(首部)_第4张图片

实体首部字段

图解HTTP(六)—— HTTP请求头(首部)_第5张图片

4、非HTTP首部字段

        在HTTP协议通信交互中使用到的首部字段,不限于RFC2612中定义的47种首部字段,还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段。这些非正式的首部字段统一归纳在RFC4229 HTTP Header Field Registrations中。

5、End-to-end 首部和Hop-by-hop首部

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

① 端到端首部

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

② 逐跳首部

        此类别中的首部只对单次转发有效,会因通过缓存或代理而不再转发。HTTP/1.1之后的版本,如果要使用此首部,需要提供Connection首部字段。

以下是HTTP/1.1中的逐跳首部:(除了这8个首部字段外,其他的所有字段都属于端到端首部)

图解HTTP(六)—— HTTP请求头(首部)_第6张图片

三、HTTP/1.1通用首部字段

1、Cache-Control

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

1.1 缓存请求指令

图解HTTP(六)—— HTTP请求头(首部)_第7张图片

1.2 缓存响应指令

图解HTTP(六)—— HTTP请求头(首部)_第8张图片

1.3 表示是否能缓存的指令

① public指令
Cache-Control:public 

 当指定public指令时,则明确表示其他用户也可利用缓存

② private指令
Cache-Control:private 

        当指定private指令时,响应只以特定的用户作为对象,这与public指令的行为相反。缓存服务器会对该用户提供资源缓存的服务,对于其他用户发送过来的请求,代理服务器不会返回缓存。

③ no-cache指令
Cache-Control:no-cache

        no-cache指令的目的是为了防止从缓存中返回过期的资源,缓存会向源服务器进行有效期确认后处理资源。

        客户端发送的请求中如果包含no-cache指令,则表示客户端不会接收缓存过的响应,缓存服务器必须把客户端请求转发给源服务器。从源服务器返回最新资源后,缓存服务器依然可以将最新资源进行缓存,然后再返回给客户端,除非服务器端也返回no-cache指令。

        服务端返回的响应中如果包含no-cache指令,那么缓存服务器不能对资源进行缓存,源服务器以后也不会再对缓存服务器请求中提出的资源有效性进行确认。

Cache-Control:no-cache=Location

        只能在响应指令中指定该参数,通过服务器端返回的指令来确定客户端是否可以使用缓存。

        客户端在接收到这个被指定参数值的报文首部后,就不能使用缓存。换句话说,无参数值的首部字段可以使用缓存。

④ no-store指令
Cache-Control:no-store
        暗示请求或响应中包含机密信息,该指令规定不进行任何缓存。

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

① s-maxage指令
Cache-Control:s-maxage=3600 (单位:秒)

       它与max-age的指令相同,不同点是s-maxage只适用于供多位用户使用的公共缓存服务器。对于向同一用户重复返回响应的服务器来说,这个指令没有任何作用。

        使用这个指令后,会直接忽略对Expires首部字段及max-age指令的处理。

② max-age指令
Cache-Control:max-age=3600 (单位:秒)

        当客户端发送的请求中包含该指令时,如果判定缓存资源的缓存时间比指定的时间数值更小,那么客户端就接收缓存的资源。如果max-age的值为0,那么缓存服务器需要将请求转发给源服务器。

        当服务器返回的响应中包含该指令时,缓存服务器将不会对资源的有效性进行确认,此时max-age代表资源保存为缓存的最长时间。

        HTTP/1.1版本的缓存服务器遇到同时存在Expires首部字段的情况时,会优先处理max-age指令,而忽略掉Expires首部字段。但是HTTP/1.0版本的缓存服务器情况却相反,max-age指令会被忽略掉。

③ min-fresh指令
Cache-Control:min-fresh=60 (单位:秒)

        这个指令要求缓存服务器返回还未过指定时间的缓存资源。

④ max-stale指令
Cache-Control:max-stale=3600 (单位:秒)

        指示缓存资源,即使过期,但只要处于max-stale指定的时间内仍然会被客户端照常接收。如果该指令未指定相应参数,那么无论过了 多久,客户端都会接收响应。

⑤ only-if-cached指令
Cache-Control:only-if-cached

        该指令要求缓存服务器不重新加载响应,也不会再次确认资源有效性,如果请求缓存服务器的本地缓存无响应,则返回状态码504。

⑥ must-revalidate指令
Cache-Control:must-revalidate

        使用该指令时,代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效,若代理无法连接源服务器获取有效资源的话,缓存必须给客户端一个504的状态码。另外,使用该指令将忽略请求的max-stale指令。

⑦ proxy-revalidate指令
Cache-Control:proxy-revalidate

        当客户端的请求包含该指令时,缓存服务器在返回响应之前,必须再次验证缓存的有效性。

⑧ no-transform指令
Cache-Control:no-transform

        该指令规定无论在请求还是在响应中,缓存都不能改变主体的媒体类型,这样可以防止缓存或代理压缩图片等类似操作。

⑨ cache-extension token
Cache-Control:private,community="UCI"

        通过cache-extension标记(token),可以扩展Cache-Control首部字段内的指令。如上添加了community这个新指令,如果缓存服务器不能够理解community这个新指令,就会直接忽略。因此,extension tokens仅对能理解它的缓存服务器有效。

2、Connection

它有两个作用:

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

Connection:Upgrade (不再转发的首部字段名)
//操作方式是将首部字段Upgrade删除后再转发

② 管理持久连接

        HTTP/1.1版本的默认连接都是持久连接(长连接),然后客户端会在持久连接上连续发送请求,当服务器想明确断开连接时,则指定Connection首部字段为Close。

Connection:Close

        HTTP/1.1之前的版本默认的都是非持久连接(短连接),如果想在旧版本的HTTP协议上维持持续连接,则需要指定Connection的值为Keep-Alive。

Keep-Alive:timeout=10,max=500
Connection:Keep-Alive

3、Date

HTTP/1.1协议使用RFC1123中规定的日期时间的格式,如下:

Date:Tue,03 Jul 2012 04:40:59 GMT

HTTP/1.1之前的协议使用RFC850中定义的格式,如下:

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

4、Pragma

        它用在客户端发送的请求中,客户端会要求所有的中间服务器不返回缓存的资源。

Pragma:no-cache

        它是HTTP/1.1之前版本的历史遗留字段,仅作为HTTP/1.0的向后兼容。如果所有的中间服务器都使用HTTP/1.1版本协议的话,那么直接使用Cache-Control:no-cache是最理想的,但所有的中间服务器使用的HTTP协议版本并不完全一致。因此,发送的请求会同时含有下面两个字段。

Cache-Control:no-cache
Pragma:no-cache

5、Trailer

此字段会事先说明在报文主体后记录了哪些首部字段,可用于HTTP/1.1版本分块传输编码时。

图解HTTP(六)—— HTTP请求头(首部)_第9张图片

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

5、Transfer-Encoding

此字段规定了传输报文主体时使用的编码方式,HTTP/1.1的传输编码方式仅对分块传输编码有效。

图解HTTP(六)—— HTTP请求头(首部)_第10张图片

6、Upgrade

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

图解HTTP(六)—— HTTP请求头(首部)_第11张图片

        在上例中,Upgrade对象仅限于客户端和邻接服务器之间,因此,在使用了Upgrade时,还需要额外指定Connection:Upgrade,对于附有Upgrade字段的请求,服务端可使用101状态码作为响应返回。

7、Via

         此字段是为了追踪客户端与服务端之间的请求和响应报文的传输路径。报文在经过代理或网关时,会先在首部字段Via中附加该服务器的信息,然后再进行转发,使用它可以避免回环的发生,所以必须在经过代理时附加该首部字段内容,如下:

图解HTTP(六)—— HTTP请求头(首部)_第12张图片

        Via首部为了追踪传输路径,经常会和TRACE方法一起使用。比如,代理服务器接收到由TRACE方法发送过来的请求(Max-Forwards:0)时,代理服务器就不能转发该请求了,这种情况下,代理服务器会将自身的信息附加到Via首部后,返回该请求的响应。

8、Warnning

该首部字段通常会告知用户一些与缓存相关的一些问题的警告。格式如下:

Warning:[警告码][警告的主机:端口号]"[警告内容]"

HTTP/1.1中定义了7种警告,如下:

图解HTTP(六)—— HTTP请求头(首部)_第13张图片

四、请求首部字段

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

1、Accept

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

       该首部字段可通知服务器,用户代理能处理的媒体类型以及媒体类型的相对优先级,可使用type/subtype这种形式,一次指定多种媒体类型。 如果想要给显示的媒体类型增加优先级,就使用q=来额外表示权重值,用" ; "进行分隔。权重值q的范围是0~1(可精确到小数点后三位),且1为最大值。不指定权重值时,默认q=1.0。当服务器提供多种内容时,将会首先返回媒体值最高的类型。

媒体类型举例如下:

图解HTTP(六)—— HTTP请求头(首部)_第14张图片

2、Accept-Charset

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

        该首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先级顺序。同样,可一次性指定多个字符集,用q=来表示字符集的相对优先级。

3、Accept-Encoding

Accept-Encoding:gzip,deflate

        该首部字段可用来通知服务器用户代理支持的内容编码及内容编码的优先级顺序。同样,可一次性指定多种内容编码,用q=来表示内容编码的相对优先级。

内容编码举例如下:

图解HTTP(六)—— HTTP请求头(首部)_第15张图片

4、Accept-Language

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

        该首部字段告知服务器用户代理能够处理的自然语言集以及自然语言集的相对优先级。同样,可一次指定多种自然语言集,用q=来表示自然语言集的相对优先级。

5、Authorization

Authorization:Basic dWVub3N1bjpwYXNzd29yZA==

        该首部字段用来告知服务器用户代理的认证信息。通常,想要通过服务器认证的用户代理会在接收到返回的401状态码响应之后,把首部字段Authorization加入请求中。共用缓存在接收到含有Authorization首部字段的请求时的操作处理有所差异。

6、From

From:[email protected]

        该首部字段用来告知服务器使用代理的用户的电子邮件地址。通常,使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。使用代理时,应尽可能使用该字段,但有的代理可能会将电子邮件地址在User-Agent首部字段内。

7、Host

Host:www.adcd.com

        该首部字段会告知服务器,请求的资源所处的互联网主机名和端口号。它是HTTP/1.1规范中唯一一个必须包含在请求内的首部字段。

        由于相同的IP地址下可能会部署运行多个域名,服务器就会无法理解究竟是哪个域名对应的请求,因此就需要使用此字段来明确的指出请求的主机名。如果服务器没有设定主机名,那直接发送一个空值即可,如下:

Host:

8、If-Match

        形如If-xxx这种形式的请求首部字段,都可称为条件请求,服务器接收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。

If-Match:"123456"

        该首部字段会告知服务器匹配资源所使用的实体标记(ETag)值,这时的服务器无法使用弱ETag值。服务器会比对If-Match的字段值和资源的ETag值,仅当再者一致时,才会执行请求。反之,则返回状态码412的响应。也可以使用" * "来指定If-Match的字段值,这时服务器将会忽略ETag的值,只要资源存在就处理请求。

9、If-None-Match

If-None-Match:*
        该首部字段与If-Match的作用相反。

10、If-Modified-Since

If-Modified-Since:Thu,15 Apr 2004 00:00:00 GMT

        该首部字段用于确认代理或客户端拥有的本地资源的有效性。它会告知服务器在些字段指定的时间后资源发生了更新就处理该请求,如果请求的资源没有更新过,则返回状态码304的响应。

11、If-Unmodified-Since

If-Modified-Since:Thu,15 Apr 2004 00:00:00 GMT

        该首部字段与If-Modified-Since的作用相反。

12、If-Range

If-Range:"123456"
Range:bytes=5001-10000

        该首部字段属于附带条件之一,它告诉服务器若指定的If-Range值(ETag值或时间)和请求资源的ETag值或时间相同时,则作为范围请求处理。否则,返回全体资源。

        如果不使用该首部字段,就需要两次处理,如下:

图解HTTP(六)—— HTTP请求头(首部)_第16张图片

13、Max-Forwards

Max-Forwards:10

        通过Trace或Options的方法发送包含该首部字段的请求时,该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一下服务器转发请求之前,会将该首部字段的值减1后重新赋值。当值为0时,请求不再进行转发,而是直接返回响应。

14、Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

        客户端接收到从代理服务器发送过来的认证质询时,客户端会发送包含该首部字段的请求,以告知服务器认证所需要的信息。

15、Range

Range:bytes=5001-10000

        客户端发送带有该首部字段的请求可以指定服务器资源的范围。接收到该首部字段的服务器,会在处理请求之后返回状态码为206 Partial Content的响应,如果无法处理该范围请求,则会返回状态码为200 OK的响应及全部资源。

16、Referer

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

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

17、TE

TE: gzip, deflate;q=0.5

        该首部字段会告知服务器客户端能够处理响应的传输编码方式以及相对优先级,它和Accept-Encoding的功能很像,但是TE只是用于传输编码。

        首部字段TE除指定传输编码之外,还可以指定伴随trailer字段的分块传输编码的方式。这时需要把trailers赋值给该字段值。如下所示:

TE: trailers

18、User-Agent

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/201001
        该首部字段将会创建请求的浏览器和用户代理名称等信息传达给服务器。

五、响应首部字段

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

1、Accept-Ranges

Accept-Ranges: bytes

        该首部字段是用于告知客户端服务器是否能处理范围请求,以指定获取服务器端某个部分的资源。它可以指定的字段值有两种,可处理范围请求时指定其为bytes,反之则指定为none。

2、Age

Age:600

      该首部字段可以告知客户端,源服务器在多久前创建了响应,字段值的单位为秒。若创建该响应的服务器是缓存服务器,Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。

3、ETag

ETag: "82e22293907ce725faf67773957acd12"

        首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag值。

① 强ETag
ETag: "usagi-1234"

        强 ETag 值,不论实体发生多么细微的变化都会改变其值。

② 弱ETag
ETag: W/"usagi-1234"
Proxy-Authenticate: Basic realm="Usagidesign Auth"

        弱 ETag 值只用于提示资源是否相同。只有资源发生了根本改变,产生差异时才会改变 ETag 值。这时,会在字段值最开始处附加 W/。

4、Location

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

        使用首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。基本上,该字段会配合 3xx :Redirection 的响应,提供重定向的URI。几乎所有的浏览器在接收到包含首部字段 Location 的响应后,都会强制性地尝试对已提示的重定向资源进行访问。

5、Proxy-Authenticate

Proxy-Authenticate: Basic realm="Usagidesign Auth"
        该首部字段会把由代理服务器所要求的认证信息发送给客户端。它与客户端和服务器之间的 HTTP 访问认证的行为相似,不同之处在于其认证行为是在客户端与代理之间进行的。而客户端与服务器之间进行认证时,首部字段 WWW-Authorization 有着相同的作用。

6、Retry-After

Retry-After: 120
        该首部字段告知客户端应该在多久之后再次发送请求。主要配合状态码 503 Service Unavailable 响应,或 3xx Redirect 响应一起使用。字段值可以指定为具体的日期时间(Wed, 04 Jul 2012 06:34:24GMT 等格式),也可以是创建响应后的秒数。

7、Server

Server: Apache/2.2.17 (Unix)
        该首部字段告知客户端当前服务器上安装的 HTTP 服务器应用程序的信息。不单单会标出服务器上的软件应用名称,还有可能包括版本号和安装时启用的可选项。

8、Vary

Vary: Accept-Language
        当代理服务器接收到带有 Vary 首部字段指定获取资源的请求时,如果与使用的 Accept-Language 字段的值相同,那么就直接从缓存返回响应。反之,则需要先从源服务器端获取资源后才能作为响应返回。

        首部字段 Vary 可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。从代理服务器接收到源服务器返回包含 Vary 指定项的响应之后,若再要进行缓存,仅对请求中含有相同 Vary 指定首部字段的请求返回缓存。即使对相同资源发起请求,但由于 Vary 指定的首部字段不相同,因此必须要从源服务器重新获取资源。

9、WWW-Authenticate

WWW-Authenticate: Basic realm="Usagidesign Auth"
        该首部字段用于 HTTP 访问认证。它会告知客户端适用于访问请求 URI 所指定资源的认证方案(Basic 或是 Digest)和带参数提示的质询(challenge)。状态码 401 Unauthorized 响应中,肯定带有首部字段 WWW-Authenticate。

六、实体首部字段

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

1、Allow

Allow: GET, HEAD
        该首部字段用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时,会以状态码405 Method Not Allowed 作为响应返回。与此同时,还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回。

2、Content-Encoding

Content-Encoding: gzip
        该首部字段会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。
        主要采取4种方式的压缩:gzip、compress、deflate、identity

3、Content-Language

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

4、Content-Length

Content-Length: 15000
        首部字段 Content-Length 表明了实体主体部分的大小(单位是字节)。对实体主体进行内容编码传输时,不能再使用 Content-Length首部字段。

5、Content-Location

Content-Location: http://www.hackr.jp/index-ja.html
        该首部字段给出与报文主体部分相对应的 URI。和首部字段 Location 不同,Content-Location 表示的是报文主体返回资源对应的 URI。

6、Content-MD5

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
        该首部字段是一串由 MD5 算法生成的值,其目的在于检查报文主体在传输过程中是否保持完整,以及确认传输到达。
       对报文主体执行 MD5 算法获得的 128 位二进制数,再通过 Base64 编码后将结果写入 Content-MD5 字段值。由于 HTTP 首部无法记录二进制值,所以要通过 Base64 编码处理。为确保报文的有效性,作为接收方的客户端会对报文主体再执行一次相同的 MD5 算法。计算出的125值与字段值作比较后,即可判断出报文主体的准确性。
        采用这种方法,对内容上的偶发性改变是无从查证的,也无法检测出恶意篡改。其中一个原因在于,内容如果能够被篡改,那么同时意味着 Content-MD5 也可重新计算然后被篡改。所以处在接收阶段的客户端是无法意识到报文主体以及首部字段 Content-MD5 是已经被篡改过的。

7、Content-Range

Content-Range: bytes 5001-10000/10000
        针对范围请求,返回响应时使用的首部字段 Content-Range,能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位,表示当前发送部分及整个实体大小。

8、Content-Type

Content-Type: text/html; charset=UTF-8
        该首部字段说明了实体主体内对象的媒体类型。和首部字段 Accept 一样,字段值用 type/subtype 形式赋值。参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值。

9、Expires

Expires: Wed, 04 Jul 2012 08:26:05 GMT
        首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段 Expires 的响应后,会以缓存来应答请求,在Expires 字段值指定的时间之前,响应的副本会一直被保存。当超过指定的时间后,缓存服务器在请求发送过来时,会转向源服务器请求资源。源服务器不希望缓存服务器对资源缓存时,最好在 Expires 字段内写入与首部字段 Date 相同的时间值。但是,当首部字段 Cache-Control 有指定 max-age 指令时,比起首部字段 Expires,会优先处理 max-age 指令。

10、Last-Modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT
        该首部字段指明资源最终修改的时间。一般来说,这个值就是 Request-URI 指定资源被修改的时间。但类似使用 CGI 脚本进行动态数据处理时,该值有可能会变成数据最终修改时的时间。

七、为Cookie服务的首部字段

        管理服务器与客户端之间状态的 Cookie,虽然没有被编入标准化HTTP/1.1 的 RFC2616 中,但在 Web 网站方面得到了广泛的应用。Cookie 的工作机制是用户识别及状态管理。Web 网站为了管理用户的状态会通过 Web 浏览器,把一些数据临时写入用户的计算机内。接着当用户访问该Web网站时,可通过通信方式取回之前发放的Cookie。调用 Cookie 时,由于可校验 Cookie 的有效期,以及发送方的域、路径、协议等信息,所以正规发布的 Cookie 内的数据不会因来自其他Web 站点和攻击者的攻击而泄露。

1、Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; pat

        响应首部字段。当服务器准备开始管理客户端的状态时,会事先告知各种信息。下表是Set-Cookie字段的属性。

图解HTTP(六)—— HTTP请求头(首部)_第17张图片

2、Cookie

Cookie: status=enable
        请求首部字段。首部字段 Cookie 会告知服务器,当客户端想获得 HTTP 状态管理支持时,就会在请求中包含从服务器接收到的 Cookie。接收到多个Cookie 时,同样可以以多个 Cookie 形式发送。

八、其他首部字段

        HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上,会出现各种非标准的首部字段。

1、X-Frame-Options

X-Frame-Options: DENY
        首部字段 X-Frame-Options 属于 HTTP 响应首部,用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持(clickjacking)攻击。

        它有两个可指定的字段值,一是DENY :拒绝,二是SAMEORIGIN :仅同源域名下的页面(Top-level-browsingcontext)匹配时许可。

2、X-XSS-Protection

X-XSS-Protection: 1
        首部字段 X-XSS-Protection 属于 HTTP 响应首部,它是针对跨站脚本攻击(XSS)的一种对策,用于控制浏览器 XSS 防护机制的开关。
        首部字段 X-XSS-Protection 可指定的字段值如下:
        0 :将 XSS 过滤设置成无效状态
        1 :将 XSS 过滤设置成有效状态

3、DNT

DNT: 1
        首部字段 DNT 属于 HTTP 请求首部,其中 DNT 是 Do Not Track 的简称,意为拒绝个人信息被收集,是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值有两个,0 :同意被追踪,1 :拒绝被追踪。

4、P3P

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS I
        首部字段 P3P 属于 HTTP 相应首部,通过利用 P3P(The Platform forPrivacy Preferences,在线隐私偏好平台)技术,可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式,以达到保护用户隐私的目的。

要进行 P3P 的设定,需按以下操作步骤进行。
步骤 1:创建 P3P 隐私
步骤 2:创建 P3P 隐私对照文件后,保存命名在 /w3c/p3p.xml
步骤 3:从 P3P 隐私中新建 Compact policies 后,输出到 HTTP 响应中
有关 P3P 的详细规范标准请参看下方链接。
The Platform for Privacy Preferences 1.0(P3P1.0)Specification
http://www.w3.org/TR/P3P/

        协议中对 X- 前缀的废除在 HTTP 等多种协议中,通过给非标准参数加上前缀 X-,来区别于标准参数,并使那些非标准的参数作为扩展变成可能。但是这种简单粗暴的做法有百害而无一益,因此在“RFC 6648 - Deprecatingthe "X-" Prefix and Similar Constructs in Application Protocols”中提议停止该做法。然而,对已经在使用中的 X- 前缀来说,不应该要求其变更。







你可能感兴趣的:(HTTP,图解HTTP)