一、简介
从web客户端发往web服务器的http报文称为请求报文（request message），从服务器发往客户端的报文称为响应报文（response message），此外没有其它类型的http报文。
http请求和响应报文的格式很类似，都包括以下3个部分：
-
起始行（start line）
报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。 -
首部字段（header）
起始后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，为了便于解析，两者之间用冒号（:）来分隔。首部以一个空格结束。添加一个首部字段和添加新行一样简单。 -
主体（body）
空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发送给web服务器的数据；响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体则不同，主体中可以包含任意的二进制数据（比如图片、视频、音轨、软件程序）。当然，主体中也可以包含文本。
GET实例
二、语法
请求报文与响应报文只有起始行的语法有所不同。
1、请求报文：
<method> <request-URL> <version>
<headers>
<entity-body>
如：
GET /test/hi.txt HTTP/1.1
Accept: text/*
Host: www.test.com
2、响应报文：
<version> <status> <reason-phrase>
<headers>
<entity-body>
如：
HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 19
Hi! I'm a message!
三、抓包
我们常用的HTTP抓包工具有如fiddler、firebug等，大家根据自己的喜好选择自己的工具。
如下是我使用firebug抓取到的一个http请求及响应包：
四、首部
HTTP首部字段可以分为如下几类：通用首部、请求首部、响应首部、实体首部、扩展首部。
每个HTTP首部都有一种简单的语法：名字后面跟着冒号（:），然后跟上可选空格，再跟上字段值，最后是一个CRLF。
1、通用首部
有些首部提供了与报文相关的最基本信息，它们被称为通用首部。客户端和服务器都可以使用这些通用首部。
| 首部 | 描述 | 举例 |
|---|---|---|
| Connection | 允许客户端和服务器端指定与请求/响应连接有关的选项 | Connection: close |
| Date | 报文创建的日期和时间 | Date: Tue, 3 Oct 1974 02:16:00 GMT |
| MIME-Version | 给出了发送端使用的MIME版本 | MIME-Version: 1.0 |
| Trailer | 说明报文拖挂中提供了哪些首部 | Trailer: Content-Length |
| Trailer-Encoding | 告知接收端为了保证报文的可选传输，对报文采用什么编码方式 | Trailer-Encoding: chunked |
| Update | 给出了发送端可能想要“升级”使用的新版本或协议 | |
| Via | 显示了报文经过的中间节点（代理、网关） | Via: joes-hardware.com (Joes-Server/1.0) |
| Cache-Control | 给出了与某个对象可缓存性有关的缓存特有指令 | Cache-Control: no-cache |
| Pragma | 用于随报文传送一些指令，但并不专用于缓存 | Pragma: no-cache |
2、请求首部
请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜好能力、服务器可以根据请求首部给出的客户端信息，试着为客户端提供更好的响应。
以下将对请求首部进行分类介绍：
- 请求的信息性首部
| 首部 | 描述 | 举例 |
|---|---|---|
| Client-IP | 提供了运行客户端的机器的IP地址 | Client-ip: 209.1.33.49 |
| From | 提供了客户端用户的E-mail地址 | From: test@inktomi.com |
| Host | 提供了客户端想要访问的那台机器的因特网主机名和端口号 | Host: www.test.com:80 |
| Referer | 使服务器知道客户端是从哪里获得其请求的URL | Referer: http://www.test.com/index.html |
| UA-Color | 客户端显示器的显示颜色有关的信息 | UA-Color: color8 |
| UA-CPU | 客户端CPU的类型或制造商 | UA-CPU: x86 |
| UA-Disp | 客户端显示器能力有关的信息 | UA-Disp: 640, 480, 8 |
| UA-OS | 客户端的操作系统名称及版本 | UA-OS: Windows 95 |
| UA-Pixels | 显示器的像素信息 | UA-Pixels: 640 x 480 |
| User-Agent | 发起请求的应用程序名称 | User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) |
- Accept首部
Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式，包括它们想要什么，可以使用什么，以及最重要的，它们不想要什么。这样，服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到它们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。
| 首部 | 描述 | 举例 |
|---|---|---|
| Accept | 告诉服务器能够发送哪些媒体类型 | Accept: text/*, image/* |
| Accept-Charset | 告诉服务器能够发送哪些字符集 | Accept-Charset: iso-latin-1 |
| Accept-Encoding | 告诉服务器能够发送哪些编码方式 | Accept-Encoding: compress;q=0.5, |
| Accept-Language | 告诉服务器能够发送哪些语言 | Accept-Language: en; q=0.7, en-gb;q=0.5 |
| TE | 告诉服务器可以使用哪些扩展传输编码 | TE: chunked |
- 条件请求首部
有时客户端希望为请求加上某些限制。比如，如果客户端已经有了一份文档副本，就希望只有服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以为请求加上这种限制，要求服务器在对请求进行响应之前，确保某个条件为真。
| 首部 | 描述 | 举例 |
|---|---|---|
| Expect | 允许客户端列出某请求所要求的服务器行为 | Expect: 100-continue |
| If-Match | 如果实体标记与文档当前的实体标记相匹配，就获取这份文档 | If-Match: "11e92a-457b-31345aa" |
| If-Modified-Since | 除非在某个指定的日期之后资源被修改过，否则就限制这个请求 | If-Modified-Since: Thu, 03 Oct 1997 17:15:00 GMT |
| If-None-Match | 如果提供的实体标记与当前文档的实体标记不相符，就获取文档 | If-None-Match: "11e92a-457b-31345aa" |
| If-Range | 允许对文档的某个范围进行条件请求 | If-Range: "11e92a-457b-31345aa" |
| If-Unmodified-Since | 除非在某个指定日期之后资源没有被修改过，否则就限制这个请求 | If-Unmodified-Since: Thu, 03 Oct 1997 17:15:00 GMT |
| Range | 如果服务器支持范围请求，就请求资源的指定范围 | Range: 500-1500 |
- 安全请求首部
HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。
| 首部 | 描述 | 举例 |
|---|---|---|
| Authorization | 包含了客户端提供给服务器，以便对其自身进行认证的数据（否则会收到401错误） | Authorization: Basic gfujhver9854fcjyf54wfku6 |
| Cookie | 客户端用它向服务器传送一个令牌（它并不是一个真正的安全首部，但确实隐含了安全功能） | Cookie: ink=ghfdytfuyt76dyc76ru5rju7ft76 |
| Cookie2 | 用来说明请求端支持的cookie版本 | Cookie2: $version="1" |
- 代理请求首部
随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。
| 首部 | 描述 | 举例 |
|---|---|---|
| Max-Forward | 这个首部只能和TRACE方法一起使用，以指定请求所经过的代理或其它中间节点的最大数目 | Max-Forward: 5 |
| Proxy-Authorization | 与Authorization首部相同，但这个首部是在与代理进行认证时使用的 | Proxy-Authorization: Basic gfujhver9854fcjyf54wfku6 |
| Proxy-Connection | 与Connection首部相同，但这个首部是在与代理建立连接时使用的 | Proxy-Connection: close |
3、响应首部
响应首部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相差的一些特殊指令。这些首部有助于客户端处理响应，并在将来发起更好的请求。
- 响应的信息首部
| 首部 | 描述 | 举例 |
|---|---|---|
| Age | （从最初创建开始）响应持续时间，以秒为单位 | Age: 60 |
| Public | 服务器为其资源支持的请求方法列表 | Public: OPTIONS, GET, HEAD, TRACE, POST |
| Retry-After | 如果资源不可用的话，在此日期或时间重试（可以与503状态码配合使用） | Retry-After: Thu, 3 Oct 1997 17:15:00 GMT |
| Server | 服务器应用程序的名称和版本 | Server: Websitepro/1.1s (s/n wpo-07d0) |
| Title | 对HTML文档来说，就是HTML文档的源端给出的标题 | Title: decument-title |
| Warning | 比原因短语中更详细的一些警告报文 | Warning: 113 |
- 协商首部
如果资源有多种表示方法——比如，如果服务器上有某文档的法语和德语稿，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。
| 首部 | 描述 | 举例 |
|---|---|---|
| Accept-Ranges | 服务器可以接受对资源的哪个范围类型进行访问 | Accept-Ranges: bytes |
| Vary | 服务器通过Vary首部来通知客户端，有服务器端的协商中会使用哪些来自客户端请求的首部。它的值是一个首部列表，服务器去查看这些首部，以确定将什么内容作为响应发回给客户端 | Vary: User-Agent |
- 安全响应首部
我们已经看到过安全请求首部了，本质上这里说的就是HTTP的质询/响应认证机制的响应侧。
| 首部 | 描述 | 举例 |
|---|---|---|
| Proxy-Authenticate | 来自代理的对客户端的质询列表 | Proxy-Authenticate: Basic realm="Super Secret Corporate FinancialDocuments" |
| Set-Cookie | Set-Cookie首部是Cookie首部的搭档。（不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识） | Set-Cookie: private_id=519; secure |
| Set-Cookie2 | 与Set-Cookie类似，是对Set-Cookie首部的扩展，RFC 2965 Cookie定义 | Set-Cookie2: ID="23453"; Domain=".test.com" |
| WWW-Authenticate | 来自服务器的对客户端的质询列表（用于401响应） | WWW-Authenticate: Basic realm="Your Private Travel Profile" |
4、实体首部
有很多首部可以用来描述HTTP报文的负荷。由于请求和响应报文中都可能包含实体部分，所以在这两种类型的报文中都有可能出现这些首部。
实体首部提供了有关实体及其内容的大量信息。
- 实体的信息首部
| 首部 | 描述 | 举例 |
|---|---|---|
| Allows | 列出了可以对此实体执行的请求方法 | Allows: GET, HEAD |
| Location | 告知客户端实体实际上位于何处；用于将接收端定向到资源的（可能是新的）位置（URL）上去 | Location: http://www.test.com |
- 内容首部
内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其它有用信息。
| 首部 | 描述 | 举例 |
|---|---|---|
| Connect-Base | 解析主体中的相对URL时使用的基础URL | Connect-Base: http://www.test.com/ |
| Connect-Encoding | 对主体执行的任意编码方式（告知客户端，服务器对对象执行过哪种或哪些类型的编码） | Connect-Encoding: gzip |
| Connect-Language | 理解主体时最适宜使用的自然语言 | Connect-Language: en |
| Connect-Length | 主体的长度或尺寸 | Connect-Length: 2434 |
| Connect-Location | 资源实际所在的位置 | Connect-Location: http://www.test.com/index.html |
| Connect-MD5 | 主体的MD5校验和 | Connect-MD5: jygi2uy3pi1guy64uyfg== |
| Connect-Range | 在整个资源中此实体列示的范围 | Connect-Range: bytes 500-999 / 5400 |
| Connect-Type | 这个主体的对象类型 | Connect-Type: text/html; charset=iso-latin-1 |
- 实体缓存首部
通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息——比如，验证已缓存的资源副本是否仍然有效所需的信息，以及更好地估计已缓存资源何时失效所需的线索。
| 首部 | 描述 | 举例 |
|---|---|---|
| ETag | 与此实体相差的实体标记 | ETag: W/"11e92a-457b-3134b6aa" |
| Expires | 实体不再有效，要从原始的源端再次获取此实体的日期和时间 | Expires: Thu, 03 Oct 1997 17:15:00 GMT |
| Last-Modified | 这个实体最后一次被修改的日期和时间 | Last-Modified: Thu, 03 Oct 1997 17:15:00 GMT |
参考
《HTTP权威指南》 David Gourley, Brian Totty, Marjorie Sayer, Sailu Reddy, Ansbu Aggarwal 著 陈涓 赵振平 译
RFC：https://tools.ietf.org/html/rfc2616（查看第14章）
W3C：https://www.w3.org/Protocols/rfc2616/rfc2616.html（查看第14章）
网友评论