HTTP协议的请求和响应报文中必定包含HTTP首部，只是我们平时在使用web的过程中感受不到它。本章我们一起来学习HTTP首部的结构，以及首部中各个字段的用法，
一、HTTP报文首部
HTTP协议的请求和响应报文中必定包含HTTP首部。首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。
报文首部由几个字段构成。
1》HTTP请求报文
在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成。
实例：www.grhao.com 请求时候报文的首部信息。
2》。HTTP响应报文
在响应中，HTTP报文由HTTP版本、状态码（数字和原因短语）、HTTP首部字段3部分构成。
实例：响应报文
在报文众多的字段当中，HTTP首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。
因HTTP版本或扩展规范的变化，首部字段可支持的字段内容略有不同。
二、HTTP首部字段
1.HTTP首部字段传递重要信息
HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务器之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。
使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。
2.HTTP首部字段结构
HTTP首部字段是由首部字段名和字段值构成的，中间用冒号“：”分隔。
首部字段名：字段值
例如：在HTTP首部中以Content-Type这个字段来表示报文主体的对象类型。
Content-Tpye : text/html
Content-Type 表示首部字段名 text/html 表示字段值
另外，字段值对应单个HTTP首部字段可以有多个值
例如：Keep-Alive：timeout=15,max=100
* 若HTTP首部字段重复了会如何
当HTTP报文首部中出现了两个或两个以上具有相容首部字段名时会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致，有些浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。
3. 4中HTTP首部字段类型
HTTP首部字段根据实际用途被分为以下4中类型。
通用首部字段（General Header Fields）：请求报文和响应报文两方都会使用的首部。
请求首部字段（Request Header Fields）：从客户端向服务端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要就客户端附加额外的内容信息。
实体首部字段（Entity Header Fields）：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等于实体有关的信息。
4.HTTP/1.1首部字段一览
表 6-2：请求首部字段
表 6-3：响应首部字段
表 6-4：实体首部字段
非HTTP/1.1 首部字段
在HTTP协议通讯交互中使用到首部字段，不限于RFC2616中定义的47种首部字段。还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段，它们的使用频率也很高。
在些非正式的首部字段统一归纳在RFC4229HTTP Header Field Registrantions中。
End-toend 首部和Hop-by-hop 首部
HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成2中类型。
端到端首部（End-to-end Header）：分在此类别中的首部会转发给请求/响应对应的最终接受目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。
逐跳首部（Hop-by-hop Header）：分在此类别中的首部只对单词转发有效，会因通过缓存或代理而不再转发。HTTP/1.1和之后版本中，如果要使用hop-by-hop首部，需提供connection首部字段。
下面列举了HTTP/1.1中的逐跳首部字段。除这8个首部字段之外，其他所有字段都属于端到端首部。
connection、keep-alive、proxy-authenticate、proxy-authorization、trailer、TE、Transfer-Encoding、Upgrede
三、HTTP/1.1通用首部字段
通用首部字段是指，请求报文和响应报文双方都会使用的首部。
1》Cache-control
通过制定首部字段Cache-Control的指令，就能操作缓存的工作机制。
指令的参数是可选的，多个制定之间通过“，”分隔。首部字段Cache-Control的指令可用于请求及响应。
Cache-Control：private，max-age=0,no-cache
^Cache-Control 指令一览
表示能否缓存的指令
1）public 指令
Cache-Control：public
当指定使用public指令时，则明确表明其他用户也可利用缓存。
2）private 指令
Cache-Control：private
当指令private指定后，响应只以特定的用户作为对象，这与public指定的行为相反。
缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。
3）no-cache 指令
Cache-Control:no-cache
使用no-cache指令的目的是为了防止从缓存中返回过期的资源。
客户端发送的请求中如果包含no-cache指令，则表示客户端将不会接收缓存过的响应。于是，‘中间’的缓存服务器必须把客户端请求转发给源服务器。
如果服务器返回的响应中包含no-cache指令，那么缓存服务器不能对资源进行缓存。源服务器以后也将不在对缓存服务器请求中提出的资源有效性进行确定，且禁止其对响应资源进行缓存操作
Cache-control:no-cache=location
由服务器返回的响应中，若报文首部字段Cache-Control中对no-cache字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不能使用缓存。换而言，无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数。
控制可执行缓存的对象的指令
4）no-store指令
Cache-Control：no-store
当使用no-store指令时，暗示请求或响应中包含机密信息。
* 从字面上很容易将no-cache误解成为不缓存，但事实上no-cache代表不缓存过期的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为do-not-server-from-cache-without-revalidation更合适。no-store才是真正地不进行缓存，请注意区分理解。
因此，该指令规定缓存不能再本地存储请求或响应的任一部分。
5）s-maxage指令（指定缓存期限和认证的指定）
Cache-Control：s-maxage=604800（单位：秒）
s-maxage指令的功能和max-age指令的相同，他们的不同点是 s-maxage指令只适用于供多位用户使用的公共缓存服务器（一般指代理）。也就是说，对于向同一用户重复返回响应的服务器来说，这个指定没有任何作用。
另外，当使用s-maxage指令后，则直接忽略对Expire是首部字段及max-age指令的处理。
6）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指令会被忽略掉
7）min-fresh指令
Cache-Control：min-fresh=60（单位：秒）
min-fresh指令要求你缓存服务器返I回至少还未过指定时间的缓存资源。
比如，当指定min-fresh为60秒后，过了60秒的资源都无法作为响应返回了。
8）max-stale指令
Cache-Control：max-stale=3600（单位：秒）
使用max-stale可指示缓存资源，即使过期也照常接收。
如果指令未指定参数值，那么无论经过多久，客户端都会接收响应；
如果指令中制定了具体数值，那么即使过期，只要仍处于max-stale指定的时间内，仍然会被客户端接收。
9）only-if-cached 指令
Canche-Control:only-if-cached
使用only-if-cached指令表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新加载响应，也不会再次确认资源的有效性。若发生请求缓存服务器的本地缓存无响应，则返回状态码504Gateway Timeout.
10)must-revalidate 指令
Canche-Control：must-revalidata
使用must-revalide指令，代理服务器再次验证即将返回的响应缓存目前是否仍然有效。
若代理无法连接原服务器再次获取有效资源的话，缓存必须给客户端一条504（Gateway Timeout）状态码。
另外，使用must-revalidate指令会忽略请求的max-state指令（及时已经在首部使用了max-state，也不会再有效果）。
11）proxy-revalldate指令
Cache-Control：proxy-revalidata
proxy-revalidate指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。
12）no-transform指令
Canche-Control：no-transform
使用n-transform指令规定无论是在请求还实在响应中，缓存都不能改变实体主体的媒体类型。
这样做可以防止缓存或代理压缩图片等类似操作。
Canche-Control扩展
13）cache-extension token
Canche-Control:private,community=“UCI”
通过cache-control首部字段本身没有community这个指令。借助extension tokens 实现了该指令的添加。如果缓存服务器不能理解community 这个新指令，就会直接忽略。因此，extension tokens仅对能理解它的缓存服务器来说是有意义的。
2》Connection
Connection首部字段有如下两个作用
1）控制不在转发给代理的首部字段
在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不在转发给代理的首部字段（即Hop-by-hop首部）
2）管理持久连接
HTTP/1.1版本默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为Close.
HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定Connection首部字段的值为Keep-Alive。
如上1图所示 ，客户端发送请求给服务器时，服务器端会像上图2那样加上首部字段keep-Alive及首部字段Connection后返回响应。
3》Date
首部字段Data表明创建HTTP报文的日期和时间。
HTTP/1.1协议在使用RFC112中规定的日期时间的格式，如下所示
Date：Tue，03 Jul 2012 04:40:59 GMT
之前的HTTP协议版本中使用在RFC850中定义的格式，如下所示
Date：Tue，03-Jul-12 04:40:59 GMT
除此以外，还有一种格式。它与C标椎库内的asctime()函数的输出格式一致。
Date：Tue Jul03 04:40:59 2012
4》Pragma
pragma 是HTTP/1.1之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。
规范的定义唯一，如下所示
Pragma ：no-cache
该首部字段属于通用首部字段，但只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。
所有的中间服务器如果都能以HTTP.1.1为基准，那直接采用Cache-Control：no-cache指定缓存的处理方式是最为理想的，但是要整体掌握全部中间服务器使用的HTTP协议版本却是不现实的。因此，发送的请求会同时含有下面两个首部字段。
Cache-Control：no-cache
Pragma:no-cache
5》trailer
首部字段trailer会事先说明在报文主体后记录可那些首部字段。该首部字段可应用在HTTP/1.1版本分块传输编码时。
以上用例中，指定首部字段Trailer的值为Expires,在报文主体之后（分块长度0之后）出现了首部字段Expires.
6》Transfer-Encoding
首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。
HTTP/1.1的传输编码方式仅对分块传输编码有效。
以上用例中，正如在首部字段Transfer-Encoding中指定的那样，有效使用分块传输编码。且分别被分为3312字节和914字节大小的分块数据。
7》Upgrade
首部在字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。
上图实例中，首部资源Upgrade指定的值为TLS/1.0。请注意此处两个字段首部字段产生作用的Upgrade对象仅限于客户端和连接服务器之间。因此，使用首部字段Upgrade时，还需要额外指定connection：Upgrade。
对于附有首部字段Upgrade的请求，服务器可用101 Switching Protocols状态码作为响应。
8》Via
使用首部字段Via 是为了追踪客户端与服务器之前的请求和响应报文的传输路径。
报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后在进行转发，这个做法和traceroute及电子邮件的Received首部的工作机制很类似。
首部字段Via不仅用于追踪报文的转发，还可避免请求回环的发生。所以必须在经过代理时附加首部字段内容。
上图用例中，在经过代理服务器A时，Via首部附加了“1.0 gw.hackr.jp(Squid/3.1)”这样的字符串值。行头的1.0是指接收请求的服务器上应用的HTTP协议版本。接下来经过代理服务器B时亦是如此，在Vai首部附加服务器信息，也可增加1个新的Via首部写入服务器信息。
Via首部时为了追踪传输路径，所以经常会和TRACE方法一起使用。比如，代理服务器接收到由TRACE方法发送过来的请求（其中Max-Forwards:0）时，代理服务器就不能再转发该请求了。这种情况下，代理服务器会将自身的信息附加到Via首部后，返回该请求的响应。
9》Warning
HTTP/1.1的warning首部从HTTP/1.0的响应首部（Retry-After）演变过来的。该首部通常会告知用户一些与缓存相关的问题和警告。
四、请求首部字段
请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。
1）Accept
Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级，可使用type/subtype这种形式，一次指定多种媒体类型。
1.文本文件
text/html.,text/plain,text/css ..... application/xhtml+xml,application/xml .......
2.图片文件
image/jpeg,image/gif,image/png,image/jpg .....
3.视频文件
video/mpeg, video/quicktime ....
4.应用程序使用的二进制文件
application/octet-stream, application/zip ...
比如，如果浏览器不吃吃PNG格式的图片显示，那么Accept就不指定image/png ，而指定可处理的image/gif 和image/jpeg 等图片类型。
若想要给显示的媒体类型增加优先级，则使用q= 来额外表示权重值(原文是“品质系数”，在RFC2616定义中，此处的q是指qvalue，即quality factor 。直译的话就是质量数，但是综合考虑理解记忆的便利性后，似乎采用权重值更为稳妥 ------ 译者注)，用分号进行分隔。权重值q的返回时0~1（可精确到小数点后三位），且1位最大值。不指定权重q值时，默认权重为q=1.0。
当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。
2）Accept-Charset
Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字段Accept相同的时可用权重q值来表示相对优先级。
该首部字段应用于内容协商机制的服务器驱动协商。
3）Accept-Encoding
Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。
1.gzip
有文件压缩程序gzip(GNU zip)生成的编码格式（RFC1952），采用Lempel-Ziv算法及32位循环冗余校验（Cyclic Redundancy Check 通称CRC）
2.compress
由UNIX文件压缩程序compress生成的编码格式，采用lempel-Ziv-Wetch 算法（LZW）
3.deflate
组合使用zlib格式（RFC1950）及由deflate压缩算法（RFC1951生成的编码格式）
4.identity
不执行压缩或不会变化的默认格式
采用权重q值来表示相对优先级，这点于首部字段Accept相同。另外，也可以使用星号（*）作为通配符，指定任意的编码格式。
4）Accept-Language
首部字段Accept-Language 用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级，可一次指定多种语言集。
和Accept首部字段一样，按权重值q来表示相对优先级。在上述图例中，客户端在服务器有中文版资源的情况下，会请求其返回中文版对应的响应，没有中文版时，则请求返回英文版响应。
5）Authorization
首部字段Authorization是用来告知服务器，用户代理的认证信息（证书值）。通常，想要通过服务器认证的用户代理会在接受到返回的（401）状态吗响应后，把首部字段Authorization加入请求中。共用缓存在接收到含有Authorization首部字段的请求时的操作处理会略有差异。
6）Expect
客户端使用首部字段Expect来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417 Expectation Failed。
客户端可以利用该首部字段，写明所期望的扩展。虽然HTTP/1.1规范只定义了100-continue（状态码100 Continue 之意）。
等状态码100响应的客户端在发生请求时，需要指定Expect：100-continue。
7）From
首部字段From用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电机邮件联系方式。使用代理时，应尽可能包含From首部字段（但可能会因代理不同，将电子邮件地址记录在User-Agent首部字段中）。
8）Host
首部字段Host会告知服务器，请求的资源所出的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须包含在请求内的首部字段。
首部字段Host和以单台服务器分配多个域名的虚拟主机的工作机制由很密切的关联，这是首部字段Host必须存在的意义。
请求被发送至服务器时，请求中的主机名会用IP地址直接替换解决。但如果这时，相同的IP地址下部署运行着多个域名，那么服务器就无法理解究竟是哪个域名对应的请求。因此，就需要使用首部字段Host来明确指出请求的主机名。若服务器未设定主机名，那直接发送一个空值即可，如下所示
Host:
9)If-Match
形如If-xxx这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件 为真时，才会执行请求。
首部字段If-Match，属于附带条件之一，它会告知服务器匹配资源所用的实体标记（ETag）值，这时的服务器无法使用弱ETag值。
服务器会比对if-Match的字段值和资源的ETag值，仅当两者一致时，才会执行请求。反之，则会返回状态码412 Precondition Failed 的响应。
还可以使用星号（*）指定if-Match的字段值。针对这种情况，服务器将会忽略ETag的值，只要资源存在就处理请求。
10）if-Modified-Since
if-Modified-Since：Thu，15 Apr 2004 00:00:00 GMT
首部字段if-Modified-Since，属附带条件之一。它会告知服务器若if-Modified-Since字段值早于资源的更新时间，则希望能处理该请求。而在指定if-Modified-Since字段值的日期之后，如果请求的资源都没有过更新，则返回状态码304 Not Modified 的响应。
if-Modified-Since用于确认代理或客户端拥有的本地资源的有效性。获取资源的更新日期时间，可通过确认首部字段Last-Modified来确定。
11）If-None-Match
首部字段If-None-Match属于附带条件之一。它和首部字段If-Match作用相反。用于指定If-None-Match字段值的实体标记（ETag）值与请求资源的ETag不一致时，它就告知服务器处理该请求。
12）If-Range
首部字段If-Range属于附带条件之一。它告知服务器若指定的If-Range字段值（ETag值或者时间）和请求资源的ETag值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
下面我们思考一下不使用首部字段If-Range发送请求的请求。服务器端的资源如果更新，那客户端持有资源中的一部分也会随之无效，当然，范围请求作为前提是无效的。这时，服务器会暂且以状态码412Precondition Failed 作为响应返回，其目的是催促客户端再次发送请求。这样一来，与使用首部字段If-Range比起来，就需要花费两倍的功夫。
13）If-Unmodified-Since
if-Unmodified-Since: Thu , 03 JuI 2012 00:00:00 GMT
首部字段If-Unmodified-Since和首部字段If-Modified-Since的作用相反。它的作用时告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定日期时间后发生了更新，则以状态码412Precondition Failed 作为响应返回。
14）Max-Forwards
Max-Forwards：10
通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数型时指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，Max-Forwards的值减1后重新赋值。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。
使用HTTP协议通信时，请求可能会经过代理等多台服务器。途中，如果代理服务器由于某些原因导致请求转发失败，客户端也就可能等不到服务器返回的响应了。对此，我们无从可知。
可以灵活使用首部字段Max-Forwards，针对以上问题产生的原因展开调查。由于当Max-Forwards字段值为0时，服务器就会立即返回响应，有次我们至少可以对以那台服务器为终点的传输路径的通信状况有所把握。
15）Proxy-Authorization
Proxy-Authorization：Basic dglw012
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。
这个行为是与客户端和服务端之间的HTTP访问认证相类似的，不同之处在于，认证行为发生在客户端与代理之间。客户端与服务器之间的认证，使用首部字段Authorization可起到相同作用。有关HTTP访问认证，后面的文章会详细说。
16）Range
Range：bates=5001-10000
对于只需获取部分资源的请求范围请求，包含首部字段Range即可告知服务器资源的指定范围。上面的实例表示请求获取从第5001字节至第10000字节的资源。
接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206 Partial Content 的响应。无法处理该范围请求时，则会返回状态码200 OK 的响应及全部资源。
17）Referer
首部字段Referer会告知服务器请求的原始资源的URI
客户端一般都会发送Referer首部字段给服务器。但当直接在浏览器的地址栏输入URI，或出于安全性的考虑时，也可以不发送该首部字段。
因为原始资源的URI中的查询字符串可能含有ID和密码等保密信息，要是写入Referer转发给其他服务器，则有可能导致保密信息的泄露。
另外，Referer的正确的拼写应该是Refer热人，但不知为何，大家一直沿用这个错误的拼写。
18）TE
TE：gzip， deflate；q=0.5
首部字段TE会告知服务器客户达UN能够处理响应的传输编码方式及相对优先级。它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。
首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分块传输编码方式。应用后者时，只需把trailers 赋值给该字段值。
TE：trailers
19)User-Agent
首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。
由网络爬虫发起请求时，有可能会在字段内添加爬虫作者的电子邮件地址。此外，如果请求经过代理，那么中间也很可能被添加上代理服务器的名称。
*在HTML嵌入APP项目中 还可以使用User-Agent表示唯一字符来表示APP环境。
五、响应首部字段
响应首部字段是由服务器端向客户端返回响应报文中所使用的的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。
1）Accept-Ranges
Accept-Ranges:bytes
首部字段Accept-Ranges是用来告知客户端服务器是否能处理范围请求，以指定获取服务器某个部分的资源。
可指定的字段只有两种，可处理范围请求时指定其为bytes，反之则指定其为none.
2)Age
首部字段Age能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。
若创建该响应的服务器是缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。
3）ETag
首部子弹ETag 能告知客户端实体标记。它是一种可将资源以字符串形式作唯一性标识的方式。服务器会为每份资源分配对应的Etag值。
另外，当资源更新时，Etag值也需要更新。生成Etag值时，并没有统一的算法规则，而仅仅是有服务器来分配。
资源被缓存时，就会被分配唯一性标识。例如，当使用中文版的浏览器访问http://www.google.com/时，就会返回中文版对应的资源，而是用英文版的浏览器访问时，则会返回英文版对应的资源。两者的URI是相同的，所以仅凭URI指定缓存的资源是相当困难的。若在下载过程中出现连续中断、在连接的情况，都会依照ETag值来指定资源。
强Etag值和弱Tag值
Etag中的强ETag值和弱ETag值之分
强ETag值：不论实体发生多么细微的变化都会改变其值。
ETag：“usagi-1234”
弱ETag值：只用于提示资源是否相同。只有资源发生了根本改变，产生差异时才会改变ETag值。这时，会在字段值最开始出附加W/。
ETag:W/"usagi-1234"
4）Location
使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。
基本上，该字段会配合3xx：Redirection的响应，都会强制性地尝试对已经提示的重定向资源的访问。
5）Proxy-Authenticate
Proxy-Authenticate：Basic realm="Usagidsign Auth"
首部字段Proxy-Authenticate会把由代理服务器所要求的认证信息发送给客户端。
它与客户端和服务器之间的http访问认证的行为相似，不同之处在于其认证行为是在客户端与代理之间进行的。而客户端与服务器之间进行认证时，首部字段WWW-Authorization有着相同的作用。
6）Retry-After
首部字段Retry-After告知客户端应该在多久之后再次发送请求。主要配合状态那503 service Unavailable 响应，或3xx Redirect 响应一起使用。
字段值可以指定为具体的日期时间，也可以是创建响应后的秒数。
7）Server
首部字段Service告知客户端当前服务器上安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
Server：Apache/2.2.6 (Unix) PHP /5.2.5
8)Vary
当代理服务器接收到带有Vary首部字段指定获取资源的请求时，如果使用的Accept-Language字段的值相同，那么就直接从缓存返回响应。反之，则需要先从源服务器端获取资源后才能作为响应返回
Vary：Accept-Language
首部字段Vary可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。
从代理服务器接收到源服务器返回包含Vary指定项的响应之后。若再要进行缓存，仅对请求中含有相同Vary指定首部字段的请求返回缓存。即使对相同资源发起请求，但由于Vary指定的首部字段不相同，因此必须要从源服务器重新获取资源。
9）WWW-Authenticate
WWW-Authenticate：Basic realm=“Usagidesign Auth”
首部子弹WWW-Authenticate用于HTTP访问认证。它会告知客户端适用于访问请求URI所指定资源的认证方案（Basic或是Digest）和带参数提示的质询（challenge）。状态码401Unauthorized响应中，肯定带有首部字段WWW-Authenticate。
上述示例中，realm字段的字符串是为了辨别请求URI指定资源所收到的保护策略。
六、实体首部字段
实体首部字段是包含在请求报文和响应报文中的实体部分所使用的的首部，用于补充内容的更新时间等于实体相关的信息。
1）Allow
首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的http方法时，会以状态码405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。
2）Content-Encoding
Content-Ecoding：gzip
首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。
主要采用一下四种内容编码的方式：gzip , compress , deflate , identity
3)Content-Language
首部自担Content-Language会告知客户端，实体主体使用的自然语言（值中文或英文等语言）
4）Content-Length
首部字段Content-Language表明了，实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不能再使用Content-Language首部字段。由于实体主体大小的计算方法略微复杂，所以在此不再展开，可参考RFC2616的4.4
5）Content-Location
Content-Location：http://ww.hackr.jp/index-ja.html
首部阻断Content-Location给出与报文主体部分相对应的URI。和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。
比如，对于使用首部字段Accept-Language的服务器驱动型请求，当返回的页面内容与实际请求的对象不同时，首部字段Content-Location内会写明URI。
6）Content-MD5
首部字段Content-MD5是一串有MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。
对于报文主体执行MD5算法获得的128位二进制数，在通过Base64编码将结果写入Content-MD5字段值。为了确保报文的有效性，作为接收方的客户端会对报文主体在执行一次相同的MD5算法。计算出的值与字段值作比较后，即可判断出报文主体的准确性。
采用这种方法，对内容上的偶发性改变是无从查证的，也无法检测出恶意篡改。其中一个原因在于，内容如果能够被篡改。所以处在接收阶段的客户端是无法意识到报文主体以及首部字段Content-MD5 是已经被篡改过的。
7)Content-Range
Content-Range：bytes 5001-10000/10000
针对范围请求，返回响应时使用的首部字段Content-Range，能否告知客户端作为响应返回的实体的那个部分符合范围请求。字段值以字节为单位，表示当前发送部分及整个实体大小。
8）Content-Type
Content-Type：text/html ; charset=UTF-8
首部字段Content-Type 说明实体主体对象的媒体类型。和首部字段Accept一样，字段值用type/subtype 形式赋值。
9）Expires
Expires:web , 04 Jul 2012 08:26:05 GMT
首部字段Expires会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段Expires的响应后，会议缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后。缓存服务器在请求发送过来时，会转向源服务器请求资源。
源服务器不希望缓存服务器对资源缓存时，最好在Expires字段内写入与首部字段Date相同的时间值。
10）Lase-Modified
Last-Modified：web,23 May 2012 09:56:55 GMT
首部字段Lase-Modified指明资源最终修改的时间。一般来说，这个值就是Request-URI指定资源被修改的时间。但类似使用CGI脚本进行动态数据处理时，该值有可能会变成数据最终修改时的时间。
七、为Cookie服务的首部字段
管理服务器与客户端之间状态的Cookie，虽然没有被编入标准化HTTP/1.1的RFC2616中，但在web网站方面得到了广泛的应用。
cookie的工作机制是用户识别及状态管理。web网站为了管理用户的状态会通过web浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该web网站时，可通过通信方式取回之前发放的Cookie。
调用Cookie时，由于可校验Cookie的有效期，以及发送发的域、路径、协议等信息，所以正规发布的cookie内的数据不会因来自其他web站点和攻击者的攻击而泄漏。
至2013年5月，Cookie，并制定相关的规范标准。1994年前后，cookie正式应用在网景浏览器中。目前最为普及的Cookie方式也是以此为基准的。
RFC2019
某企业尝试以独立技术对Cookie规格进行标准化统筹。原本的意图是想和网景公司制定的标准交互应用，可以发生和微妙的差异，现在该标准已经淡出人们的视线了。
RFC2965
为终结Internet Explorer浏览器与Netscape Navigation 的标准差异而导致的浏览器战争，RFC2965内定义了新的HTTP首部Set-Cookie2和Cookie2.可事实上，它们几乎没怎么投入使用。
RFC6265
将网景公司制定的标准作为业界实标准（De facto standard）,重新定义Cookie标准后的产物。
目前使用最广泛的Cookie标准却不是RFC中定义的任何一个。而是在网景公司指定的标准上进行扩展后的产物。
1）Set-Cookie
Set-Cookie：status=enable;expirers=Tue,05 Jul 2011 07:10:12
当服务器准备开始管理客户端的状态时，会事先告知各种信息。
1.expires属性
cookie的expires属性指定浏览器可发送Cookie的有效期。
当省略expires属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用成语被关闭之前。
另外，一旦Cookie从服务器端发送至客户端，服务器端就不存在可以显示删除Cookie的方法。但可通过覆盖已过期的Cookie，实现对客户端的Cookie的实质性删除操作。
2.path 属性
Cookie的path属性可用于限制指定Cookie的发送范围的文件目录。不过另外有办法可避开这项限制，看来对其作为安全机制的效果不能抱有期待。
3.domain属性
通过Cookie的domain属性指定的域名可做到与结尾匹配一致。比如，当指定example.com后，除example.com以外，www.example或www2.example.com等都可以发送Cookie。
因此，除了针对具体指定的多个域名发送Cookie之外，不指定domain属性显得更安全。
3，secure属性
Cookie的secure属性用于限制web页面仅在https安全链接时，才可以发送Cookie。
发送Cookie时，指定secure属性的方法如下所示。
Set-Cookie：name=value;secure
以上例子仅当在https://www.xxx.com/ （https）安全连接的情况下才会进行Cookie的回收。也就是说，即使域名相同，http://www.xxx.com （HTTP）也不会发生Cookie回收行为。
当省略secure属性时，不论HTTP还是https，都会对Cookie进行回收。
HttpOnly属性
Cookie的HTTPOnly属性时Cookie的扩展功能，它使JavaScript脚本无法获得Cookie。其主要目的是为防止跨站脚本攻击（Cross-site-scripting，XSS）对Cookie的信息窃取。
发送指定HttpPnly属性的Cookie的方法如下所示。
Set-Cookie:name-value;httpOnly
通过上述设置，通常从Web页面内还可以对Cookie进行读取操作。但使用JavaScript的documen.cookie就无法读取附近HttpOnly属性后的Cookie的内容了。因此，也就无法在XSS中利用JavaScript劫持Cookie了、
虽然是独立的扩展功能，但Internet Explorer 6 SPL以上版本等当下的主流浏览器都已经支持该扩展了。另外顺带一提，该扩展并非是为了防止XSS攻击而开发的。
2）Cookie
Cookie：status=enable
首部字段Cookie会告知服务器，当客户端想获取HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie形式发送。
八、其他首部字段
HTTP首部字段是可以自行扩展的。所以在web服务器和浏览器的应用上，会出现各种非标准的首部字段。
接下来。对一些常用的字段进行说明。
X-Frame-Options、X-XSS-Protection、DNT、P3P
1）X-Frame-Options
X-Frame-Options：DENY
首部字段X-Frame-Options属于HTTP响应首部，用于控制网站内容在其他web网站的Frame标签内的显示问题。其主要目的是为了防止点击劫持（clickJacking）攻击。
首部字段X-Frame-Options有以下两个可指定的字段值。
DENY：拒绝
SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context）匹配时许可。（比如，当指定http://harckr.jp/sample.html页面为SAMEORIGIN时，那么hackr.jp上所有页面的frame都被允许可加载该页面，而example.com等其他域名的页面就不行了）
支持该首部字段的浏览器有：Internet Explorer 8、 Firefox 3.6.9+/chrome 4.1.249.1042+、Safari 4 + 和 Opera 10.50 + 等。现在主流浏览器都已经支持。
能在所有的web服务器端预定设好X-Frame-Options字段值是最理想的状态。
对apache2.conf的配置实例
Header append X-FRAME_OPTIONS "SAMEORIGIN"
2)X-XSS-Protection
X-XSS-Protection:1
首部字段X-XSS-Protection属于HTTP响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器XSS防护机制的开关。
首部字段X-XSS-Protection可指定的字段值如下。
0：将XSS过滤设置成无效状态
1：将XSS过滤设置成有效状态
3）DNT
首部字段DNT属于HTTP请求首部，其中DNT是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。
首部字段DNT可指定的字段值。
0：同意被追踪
1：拒绝被追踪
由于首部字段DNT的功能具备有效性，所以Web服务器需要对DNT做对应的支持。
4)P3P
P3P:CP= "CAP DSP LAW CUPa "
首部字段P3P属于HTTP相应首部，通过利用P3P（the Platform for Privacy Preferences,在线隐私偏好平台）技术，可以让Web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。
要进行P3P的设定，需按以下操作步骤进行。
步骤1：创建P3P隐私
步骤2：创建P3P隐私对照文件后，保存命名在/w3c/p3p.xml
步骤3：从P3P隐私中新建Compact policies 后，输出到HTTP响应中
有关P3P的详细规范标准请参看
The Platform for Privacy Prefereness 1.0(P3P1.0) Specification http://www.w3.org/TR/P3P/
协议中对X-前缀的废除
在HTTP等多种协议中，通过给非标准参数加上前缀X-，来区别于标准参数，并使用那些非标准的参数作为扩展变为可能。但是这种简单粗暴的做法百害而无一益，因此在“RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols ”中提议停止该做法。
然而，对已经在使用中的X-前缀来说，不应该要求其变更。