HTTP 首部字段详细介绍

本文是HTTP解析系列第二篇，如果对http协议不是很了解，可以选去看第一篇：带新手走进神秘的HTTP协议，本文主要是对Http的首部字段进行详细解析。

HTTP 协议的请求和响应报文中必定包含 HTTP 首部，只是我们平时在使用 Web 的过程中感受不到它。本章 我们一起来学习 HTTP 首部的结构，以及首部中各字段的用法。

6.1 HTTP 报文首部

首部内容为客户端和服务器分别处理请求和响应提供 所需要的信息。对于客户端用户来说，这些信息中的大部分内容都无须亲自查看。

HTTP 请求报文

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

下面的示例是访问 http://hackr.jp 时，请求报文的首部信息。

GET / HTTP/1.1 
Host: hackr.jp 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8 
Accept-Language: ja,en-us;q=0.7,en;q=0.3 
Accept-Encoding: gzip, deflate DNT: 1 
Connection: keep-alive 
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT 
If-None-Match: "45bae1-16a-46d776ac" 
Cache-Control: max-age=0

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

图：响应报文 
以下示例是之前请求访问 http://hackr.jp/ 时，返回的响应报文的首部信息。

HTTP/1.1 304 Not Modified 
Date: Thu, 07 Jun 2012 07:21:36 GMT 
Server: Apache 
Connection: close 
Etag: "45bae1-16a-46d776ac"　

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。
因 HTTP 版本或扩展规范的变化，首部字段可支持的字段内容略有不同。本书主要涉及 HTTP/1.1 及常用的 首部字段。

6.2 HTTP 首部字段

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

6.2.1　HTTP 首部字段结构

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

  首部字段名: 字段值

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

Content-Type: text/html

就以上述示例来看，首部字段名为 Content-Type，字符串 text/html 是字段值。
另外，字段值对应单个 HTTP 首部字段可以有多个值，如下所示。

Keep-Alive: timeout=15, max=100

注意：若 HTTP 首部字段重复了会如何？
当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致。有些浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。

6.2.2   4 种 HTTP 首部字段类型

HTTP 首部字段根据实际用途被分为以下 4 种类型：
通用首部字段（General Header Fields）
请求报文和响应报文两方都会使用的首部。
请求首部字段（Request Header Fields）
从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段（Response Header Fields）
从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段（Entity Header Fields）
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

6.2.3　HTTP/1.1 首部字段一览

HTTP/1.1 规范定义了如下 47 种首部字段。
表 6-1：通用首部字段

表 6-2：请求首部字段

首部字段名                  说明
Accept                         用户代理可处理的媒体类型
Accept-Charset            优先的字符集
Accept-Encoding         优先的内容编码
Accept-Language        优先的语言（自然语言）
Authorization               Web认证信息
Expect                          期待服务器的特定行为
From                             用户的电子邮箱地址
Host                              请求资源所在服务器
If-Match                        比较实体标记（ETag）
If-Modified-Since          比较资源的更新时间
If-None-Match              比较实体标记（与 If-Match 相反）
If-Range                        资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since     比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards               最大传输逐跳数
Proxy-Authorization     代理服务器要求客户端的认证信息
Range                           实体的字节范围请求
Referer                          对请求中 URI 的原始获取方
TE                                  传输编码的优先级
User-Agent                   HTTP 客户端程序的信息

表 6-3：响应首部字段 

首部字段名                     说明
Accept-Ranges             是否接受字节范围请求
Age                               推算资源创建经过时间
ETag                              资源的匹配信息
Location                        令客户端重定向至指定URI
Proxy-Authenticate      代理服务器对客户端的认证信息
Retry-After                   对再次发起请求的时机要求
Server HTTP                  服务器的安装信息
Vary                              代理服务器缓存的管理信息
WWW-Authenticate     服务器对客户端的认证信息

表 6-4：实体首部字段

首部字段名                    说明
Allow                            资源可支持的HTTP方法
Content-Encoding       实体主体适用的编码方式
Content-Language      实体主体的自然语言
Content-Length           实体主体的大小（单位：字节）
Content-Location        替代对应资源的URI
Content-MD5              实体主体的报文摘要
Content-Range            实体主体的位置范围
Content-Type              实体主体的媒体类型
Expires                         实体主体过期的日期时间
Last-Modified              资源的最后修改日期时间

6.2.4  非 HTTP/1.1 首部字段

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

6.2.6　End-to-end 首部和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
• Upgrade

6.3　HTTP/1.1 通用首部字段

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

6.3.1  Cache-Control

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

图：首部字段Cache-Control 能能够控制缓存的行为 

指令的参数是可选的，多个指令之间通过“,”分隔。首部字段 Cache-Control 的指令可用于请求及响应时。

Cache-Control: private, max-age=0, no-cache​

Cache-Control 指令一览:

可用的指令按请求和响应分类如下所示。
表 6-5：缓存请求指令
指令                                  参数         说明
no-cache                          无            强制向源服务器再次验证
no-store 无 不缓存请求或响应的任何内容
max-age = [ 秒] 必需 响应的最大Age值
max-stale( = [ 秒])
可省 略
接收已过期的响应
min-fresh = [ 秒] 必需 期望在指定时间内的响应仍有效
no-transform 无 代理不可更改媒体类型
only-if-cached 无 从缓存获取资源
cache-extension - 新指令标记（token）

表 6-6：缓存响应指令

指令                                 参数           说明
public                              无              可向任意方提供响应的缓存
private                            可省略        仅向特定用户返回响应
no-cache                        可省略        缓存前必须先确认其有效性
no-store                         无              不缓存请求或响应的任何内容
no-transform                 无               代理不可更改媒体类型
must-revalidate             无              可缓存但必须再向源服务器进行确认
proxy-revalidate            无              要求中间缓存服务器对缓存的响应有效性再进行 确认
max-age = [ 秒]            必需            响应的最大Age值
s-maxage = [ 秒]          必需             公共缓存服务器响应的最大Age值
cache-extension           -                 新指令标记（token）

剩下的内容是对上面字段的解析，在 ppt 87页，实在太多了，需要时去看。

6.3.2  Connection

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

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

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

Connection: 不再转发的首部字段名

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

  2. 管理持久连接 

 

Connection: close

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

Connection: Keep-Alive　

HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为此，如果想在旧版本的 HTTP 协议上维持 持续连接，则需要指定 Connection 首部字段的值为 Keep-Alive。
如上图①所示，客户端发送请求给服务器时，服务器端会像上图②那样加上首部字段 Keep-Alive 及首部字段 Connection 后返回响应。

太多了，下边的内容只记重要的部分，做了省略。ppt 93页

6.3.3　Date 首部字段

Date 表明创建 HTTP 报文的日期和时间

6.3.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​

6.3.5　Trailer

 

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

HTTP/1.1 200 OK 
Date: Tue, 03 Jul 2012 04:40:56 GMT 
Content-Type: text/html 
... 
Transfer-Encoding: chunked 
Trailer: Expires
...(报文主体)... 
0 
Expires: Tue, 28 Sep 2004 23:59:59 GMT

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

6.3.6　Transfer-Encoding

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

HTTP/1.1 200 OK 
Date: Tue, 03 Jul 2012 04:40:56 GMT 
Cache-Control: public, max-age=604800 
Content-Type: text/javascript; charset=utf-8 
Expires: Tue, 10 Jul 2012 04:40:56 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 字节大小的分块数据。

6.3.7　Upgrade

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

6.3.8　Via

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

6.3.9　Warning

HTTP/1.1 的 Warning 首部是从 HTTP/1.0 的响应首部（Retry-After）演变过来的。该首部通常会告知用户一 些与缓存相关的问题的警告。

Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03 Jul 2012 05:09:44 GMT

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

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

ppt 95页左右

6.4　　请求首部字段

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

6.4.1　　Accept

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

Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用 type/subtype 这种形式，一次指定多种媒体类型。
下面我们试举几个媒体类型的例子。

文本文件

text/html, text/plain, text/css ...
application/xhtml+xml, application/xml ...​

图片文件

image/jpeg, image/gif, image/png ...​

视频文件

video/mpeg, video/quicktime ...​

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

application/octet-stream, application/zip ...​

比如，如果浏览器不支持 PNG 图片的显示，那 Accept 就不指定 image/png，而指定可处理的 image/gif 和 image/jpeg 等图片类型。 若想要给显示的媒体类型增加优先级，则使用 q= 来额外表示权重值 1，用分号（;）进行分隔。权重值 q 的 范围是 0~1（可精确到小数点后 3 位），且 1 为最大值。不指定权重 q 值时，默认权重为 q=1.0。
1 原文是“品質係数”。在 RFC2616 定义中，此处的 q 是指 qvalue，即 quality factor。直译的话就是质量数，但经过综合考虑理 解记忆的便利性后，似乎采用权重值更为稳妥。——译者注
当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

6.4.2　　Accept-Charset

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

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次 性指定多种字符集。与首部字段 Accept 相同的是可用权重 q 值来表示相对优先级。
该首部字段应用于内容协商机制的服务器驱动协商。

6.4.3　Accept-Encoding

Accept-Encoding: gzip, deflate​

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指 定多种内容编码。
下面试举出几个内容编码的例子。
  gzip
   由文件压缩程序 gzip（GNU zip）生成的编码格式（RFC1952），采用 Lempel-Ziv 算法    （LZ77）及 32 位循环冗余校验（Cyclic Redundancy Check，通称 CRC）。
    compress
    由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel-Ziv-Welch 算法（LZW）。
    deflate
    组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法（RFC1951）生成的编码格式。
    identity
    不执行压缩或不会变化的默认编码格式
采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。另外，也可使用星号（*）作为通配符，指 定任意的编码格式。

6.4.4　Accept-Language

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

首部字段 Accept-Language 用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然 语言集的相对优先级。可一次指定多种自然语言集。
和 Accept 首部字段一样，按权重值 q 来表示相对优先级。在上述图例中，客户端在服务器有中文版资源的情 况下，会请求其返回中文版对应的响应，没有中文版时，则请求返回英文版响应。

6.4.5　Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==​

首部字段 Authorization 是用来告知服务器，用户代理的认证信息（证书值）。通常，想要通过服务器认证的 用户代理会在接收到返回的 401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存在接收到含 有 Authorization 首部字段的请求时的操作处理会略有差异。
有关 HTTP 访问认证及 Authorization 首部字段，稍后的章节还会详细说明。另外，读者也可参阅 RFC2616。

6.4.6　Expect

Expect: 100-continue​

客户端使用首部字段 Expect 来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出 回应而发生错误时，会返回状态码 417 Expectation Failed。
客户端可以利用该首部字段，写明所期望的扩展。虽然 HTTP/1.1 规范只定义了 100-continue（状态码 100 Continue 之意）。
等待状态码 100 响应的客户端在发生请求时，需要指定 Expect:100-continue

6.4.7  From

首部字段 From 用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索 引擎等用户代理的负责人的电子邮件联系方式。使用代理时，应尽可能包含 From 首部字段（但可能会因代 理不同，将电子邮件地址记录在 User-Agent 首部字段内）。

6.4.8　　Host

Host: www.hackr.jp​

首部字段 Host 会告知服务器，请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段。
首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段 Host 必须存在的意义。

6.4.9  If-xxx 

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

每个if的详细内容去看ppt106页，实在是太多了

6.4.16　　Range

Range: bytes=5001-10000​

对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服务器资源的指定范围。上面的示例表示 请求获取从第 5001 字节至第 10000 字节的资源。

6.4.19　User-Agent

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

首部字段 User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器。
由网络爬虫发起请求时，有可能会在字段内添加爬虫作者的电子邮件地址。此外，如果请求经过代理，那么 中间也很可能被添加上代理服务器的名称。

6.5　响应首部字段

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

6.5.1　　Accept-Ranges

当不能处理范围请求时，Accept-Ranges: none

Accept-Ranges: bytes​

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

6.5.2　　Age

Age: 600​

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

6.6　　实体首部字段

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

6.6.1　　Allow

Allow: GET, HEAD​

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

6.6.2　　Content-Encoding

Content-Encoding: gzip

首部字段 Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不 丢失实体信息的前提下所进行的压缩。

主要采用以下 4 种内容编码的方式。（各方式的说明请参考 6.4.3 节 Accept-Encoding 首部字段）。
gzip
compress
deflate
identity

6.6.3　Content-Language

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

6.6.4　Content-Length

Content-Length: 15000
首部字段 Content-Length 表明了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不 能再使用 Content-Length 首部字段。由于实体主体大小的计算方法略微复杂，所以在此不再展开。

6.6.5　　Content-Location

Content-Location: http://www.hackr.jp/index-ja.html​

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

比如，对于使用首部字段 Accept-Language 的服务器驱动型请求，当返回的页面内容与实际请求的对象不同 时，首部字段 Content-Location 内会写明 URI。（访问 http://www.hackr.jp/ 返回的对象却是 http://www.hackr.jp/index-ja.html 等类似情况）

6.6.6　Content-MD5

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于检查报文主体在传输过程中是否保持完 整，以及确认传输到达。

6.6.7　　Content-Range

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

6.6.8　　Content-Type

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

6.6.9　　Expires

Expires: Wed, 04 Jul 2012 08:26:05 GMT

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在 Expires 字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后， 缓存服务器在请求发送过来时，会转向源服务器请求资源。

6.6.10　　Last-Modified

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

ppt 121页

6.7　为 Cookie 服务的首部字段  

ppt 125页

管理服务器与客户端之间状态的 Cookie，虽然没有被编入标准化 HTTP/1.1 的 RFC2616 中，但在 Web 网 站方面得到了广泛的应用。
Cookie 的工作机制是用户识别及状态管理。Web 网站为了管理用户的状态会通过 Web 浏览器，把一些数据 临时写入用户的计算机内。接着当用户访问该Web网站时，可通过通信方式取回之前发放的 Cookie。

下面的表格内列举了与 Cookie 有关的首部字段。

表 6-8：为 Cookie 服务的首部字段

首部字段名                 说明                                                 首部类型
Set-Cookie                开始状态管理所使用的Cookie信息     响应首部字段
Cookie                      服务器接收到的Cookie信息                请求首部字段

6.7.1　　Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;​

当服务器准备开始管理客户端的状态时，会事先告知各种信息。
下面的表格列举了 Set-Cookie 的字段值。

表 6-9：：Set-Cookie 字段的属性
属性                                说明
NAME=VALUE               赋予 Cookie 的名称和其值（必需项）
expires=DATE               Cookie的有效期（若不明确指定则默认为浏览器关闭前为止）
path=PATH                   将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档 所在的文件目录）
domain=域名                作为 Cookie 适用对象的域名 （若不指定则默认为创建 Cookie 的服务 器的域名）
Secure                           仅在 HTTPS 安全通信时才会发送 Cookie
HttpOnly                       加以限制，使 Cookie 不能被 JavaScript 脚本访问

expires 属性

Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。
当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。
另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。

6.7.2　　Cookie

Cookie: status=enable

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

6.8　其他首部字段

HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上，会出现各种非标准的首部字段。
接下来，我们就一些最为常用的首部字段进行说明。

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

上面字段的详细说明去看ppt128页

这篇和上一篇带新手走进神秘的HTTP协议，你基本就对HTTP有个详细的了解了。还剩下一点HTTPS，HTTPS介绍在下篇博文中。

本文内容摘自：图解HTTP，可以自行去下载它的ppt，在CSDN上有很多，找不到的可以在下边评论，我发给你，彩色版、黑白版都有。

转发请注明出处：http://www.cnblogs.com/jycboy/p/http_head.html