http报文

我们在学web的时候总是对从网络上抓取数据包并对数据包进行分析，而我们见到最多的接触最多的就是http报文了，这边博客作为我对http报文的一个总结。

HTTP报文分为请求报文(request message)与响应报文(response message)。

 接下来我们看该报文的具体组成部分：

1. 起始行(start line)
2. 头部(header)
3. 主体(body)

 示例：

HTTP/1.0 200 OK    //起始行

Content-type:text/plain    //首部
Content-length:19            //首部  

Hi I'm a message!    主体

请求报文的格式与响应报文的格式

请求报文的格式：

<method> <request-UTL> <version>
<headers>
(头部与主题之间有一个空行隔开，就好像这个空格一样)
<entity-body>

响应报文的格式：

<version> <status><reason-phrase>
<header>
            （这是空行）
<entity-body>

 

下面是对格式中各部分的简要描述

　　1、方法(method)　

　　　　客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD或POST。

 

　　下面给出请求报文中方法的列表

方法　　　　　　　　描述　　　　　　　　　　　　　　　　　　　　是否包含主体
GET 　　　　从服务器获取一份文档 　　　　　　　　 　　　　　　　　　否
HEAD 　　　只从服务器获取文档的首部 　　　　　　  　　　　　　　　   否
POST 　　   向服务器发送需要处理的数据　　　　　　　　　　　　　　　是
PUT 　　　　将请求的主体部分存储在服务器上 　　　  　　　　　　　　　是
TRACE 　　 对可能经过代理服务器传送到服务器上去的报文进行跟踪 　　  否
OPTIONS 　 决定可以在服务器上执行哪些方法 　　　　　　　　　　　　  否
DELETE 　　从服务器上删除一份文档 　　　　　　　　　　　　　　　　  否

　　2、请求的URL(request-URL)　　

　　　　一个完整的包括类型、主机名和可选路径名的统一资源引用名，如：http://www.example.com/path/to/file.html

　　3、版本(version)　　HTTP/1.1

　　　　报文所使用的HTTP版本，其格式如下：

　　　　HTTP/<major>.<minor>

　　　　其中主要版本号(major)和次要版本号(minor)都是整数。　　

　　4、状态码(status)

　　　　这三个数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别("成功"、"出错"等)。　　

状态码	状态描述	简要说明
200	OK	客户端请求成功
201	Created	请求已经被实现，而且有一个新的资源已经依据请求的需要而创建，且其URI已经随Location头信息返回。
301	Moved Permanently	被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一
302	Found	在响应报文中使用首部“Location: URL”指定临时资源位置
304	Not Modified	条件式请求中使用
403	Forbidden	请求被服务器拒绝
404	Not Found	服务器无法找到请求的URL
405	Method Not Allowed	不允许使用此方法请求相应的URL
500	Internal Server Error	服务器内部错误
502	Bad Gateway	代理服务器从上游收到了一条伪响应
503	Service Unavailable	服务器此时无法提供服务，但将来可能可用
505	HTTP Version Not Supported	服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

　　

下面给出状态码的常用分类

整体范围 　　　　  已定义范围 　　分类
100-199	　　　　	100-101	　　	信息提示
200-299	　　　　	200-206　　 	成功
300-399	　　　　	300-305　　 	重定向
400-499	　　　　	400-415　　 	客户端错误
500-599	　　　　	500-505　　 	服务器错误

 200-OK-成功，请求的所有数据都在响应主体中。401-Unauthorized(未授权)-需要输入用户名和密码。404-Not Found(未找到)-服务器无法找到所请求URL对应的资源。

        5、原因短语(reason-phrase)

 

　　　　数字状态码的可读版本，包含行终止序列之前的所有文本。原因短语只是给人类看的，它不能说明什么。客户端依然采用状态码来判断请求/响应是否成功！

　　　　例如：HTTP/1.0 200 NOT OK 客户端依然会当请求已成功处理。因为状态码是200。而原因短语只是说明而已，这对于自定义扩展状态码还是比较有用的。

　　 6、头部(header)

　　　　可以有0个或多个头部，每个头部都是一个键值对，在冒号后是一个可选的空格，一般都有一个空格。

通用部：既可以出现在请求报文中，也可以出现在响应报文中。

　　　　　　这些是客户端和服务器都可以使用的通用头部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。他们像和事佬一样，不论报文是何种类型，都为其提供一些有用的信息。例如不管是构建请求报文还是响应报文，创建报文的日期时间都是同一个意思，因此提供这类信息的首部对这两种类型的报文来说都是通用的。

　　　　通用的信息性头部：

头部 　　　　　　　　　　描述
Connection 　　　　　　 允许客户端和服务器指定与请求/响应连接有关的选项
Date 　　　　　　　　　  提供日期和时间标志，说明报文是什么时间创建的
MIME-Version 　　　　　 给出了发送端使用的MIME版本
Trailer 　　　　　　　　　如果报文采用了分块传输编码(chunked transfer encoding)方式，就可以用这个首部列出位于报文拖鞋 (trailer)部分的首部集合。
Transfer-Encoding 　　  告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。
Update 　　　　　　　　 给出了发送端可能想要"升级"使用的新版本或协议
Via 　　　　　　　　　　 显示了报文经过的中间节点(代理、网关)

通用缓存首部：

首部 　　　　　　　　　　描述
Cache-Control 　　　　  用于随报文传送缓存指示
Pragma 　　　　　　　　 另一种随报文传送指示的方式，但并不专用于缓存

请求首部：提供更多有关请求的信息。

　　　　　　请求首部是在请求报文中有意义的首部。用于说明是谁或什么在发送请求，请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部给出的客户端的信息，试着为客户端提供更好的响应。

请求的   信息性首部：
首部 　　　　　　　　　　　　 描述
Client-IP 　　　　　　　　　　提供了运行客户端的机器的IP地址
From 　　　　　　　　　　　  提供了客户端用户的E-mail地址
Host 　　　　　　　　　　　   给出了接收请求的服务器的主机名和端口号
Referer 　　　　　　　　　　  提供了包含当前请求URI的文档的URL
UA-Color 　　　　　　　　　  提供了与客户端显示器的显示颜色有关的信息
UA-CPU 　　　　　　　　　　 给出了客户端CPU的类型或制造商
US-Disp 　　　　　　　　　　提供了与客户端显示器(屏幕)能力有关的信息
US-OS 　　　　　　　　　　  给出了客户端显示器的像素信息
UA-Pixels 　　　　　　　　　 提供了客户端显示器的像素信息
User-Agent 　　　　　　　　 将发起请求的应用程序名称告知服务器(User-Agent)用户代理，其实不就是浏览器吗

　　Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式，包括他们想要什么，可以使用什么，以及最重要的，他们不想要什么。这样服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到他们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。

Accept首部：
首部 　　　　　　　　　　 描述
Accept 　　　　　　　　   告诉服务器能够发送哪些媒体类型
Accept-Charset 　　　　  告诉服务器能够发送哪些字符集
Accept-Encoding 　　　　告诉服务器能够发送哪些编码方式
Accept-Language 　　　  告诉服务器能够发送哪些语言
TE 　　　　　　　　　　　 告诉服务器可以使用哪些扩展传输编码

安全请求首部：

HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。

安全请求首部:
首部 　　　　　　　　　　 描述
Authorization 　　　　　  包含了客户端提供给服务器，以便对其自身进行认证的数据
Cookie 　　　　　　　　　 客户端用它想服务器传送一个令牌-他并不是真正的安全首部，但却是隐含了安全功能
Cookie2 　　　　　　　　  用来说明请求端支持的cookie版本

 

响应首部：提供更多有关响应的信息。

　　　　　　响应报文由自己的响应首部集。响应首部为客户端提供了一些额外的信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客户端处理响应，并在将来发起更好的请求。

响应的信息性首部：
首部 　　　　　　　　 描述
Age 　　　　　　　　 (从最初创建开始)响应持续时间
Public 　　　　　　　  服务器为其资源支持的请求方法列表
Retry-After 　　　　  如果资源不可用的话，再次日期或时间重试
Server 　　　　　　　 服务器应用程序软件的名称和版本
Title 　　　　　　　　 对HTML文档来说，就是HTML文档的源端给出的标题
Warning 　　　　　　 比原因短语中更详细的一些警告报文

　协商首部：如果资源有多种表示方法-比如，如果服务器上有某文档的法语和德语译稿，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。

协商首部：
首部　　　　　　　　 描述
Accept-Ranges 　　 对此资源来说，服务器可接受的范围类型
 

安全响应首部：

我们已经看到过安全请求首部了，本质上这里说的就是HTTP的质询/响应认证机制的响应侧。

安全响应首部：
首部 描述
Proxy-Authenticate 来自代理的对客户端的质询列表
Set-Cookie 不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识。
Set-Cookie2 与Set-Cookie类似。
WWW-Authenticate 来自服务器的对客户端的质询列表

实体首部：描述主体的长度和内容，或者资源自身。

　　　　

实体信息性首部：
首部 　　　　　　　描述
Allow 　　　　　　 列出了可以对此实体执行的请求方法
Location 　　　　  表示客户应当到哪里去提取文档

内容首部：

　　　　内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。比如，Web浏览器可以通过查看返回的内容类型，得知如何显示对象。

内容首部：
首部 　　　　　　　　　　　  描述
Content-Base 　　　　　　  解析主体中的相对URL时使用的基础URL
Content-Encoding 　　　　  对主体执行的任意编码方式
Content-Language 　　　　 理解主体时最适宜使用的自然语言
Content-Length 　　　　　  主体的长度或尺寸
Content-Location 　　　　　资源实际所处的位置
Content-MD5 　　　　　　　主体的MD5校验
Content-Range 　　　　　　在整个资源中此实体表示的字节范围
Content-Type 　　　　　　  这个主体的对象模型

 

　　7、实体的主体部分(entity-body)

　　　　实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分。如GET请求就不包含实体。

       HTTP的第三部分是可选的实体主体部分，实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。

　　HTTP报文可以承载很多类型的数字数据，图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。

 

       而响应的报文实体部分就是html源代码了