HTTP报文-蒲公英云

报文简述

什么是报文
报文是HTTP中客户端和服务端之间互相传递的信息，类似于我们人类的“话”，“信”。
流向
在HTTP中，一个报文的传输是只有一个方向的，客户端发送出去的报文是不能再回到客户端。并且HTTP中的服务端是不会主动发出报文的，如果有这个需求可以看websocket或者HTTP 的 SSE。
组成
HTTP的报文包含起始行，首部以及可有可无的主体。

HTTP的规范中是要求每一行的结束都要用CRLF。首部的最后要是一个空行，用于标识首部结束主体的开始。

报文的语法

请求报文和响应报文
报文分两种请求报文和响应报文。请求报文用于描述客户端想干什么，而响应报文用于描述结果。举个栗子：A对B说：给我倒杯水。（这就是请求报文）B对A说：你要脸不。（这就是响应报文）
请求报文的格式：

响应报文：
举个栗子：
请求报文：

响应报文：

起始行

方法
方法用于描述请求的性质，是获取什么，还是删除什么等等。其中获取某些东西的方法被称为安全方法，这些方法目前有（GET和HEAD）。其实这些方法的具体功能还是要看WEB程序员怎么实现，如果你就想用GET方法表示删除，那也是能实现的。
GET方法通常用于获取某些资源，类似于数据库中的DQL。
HEAD这个方法也是获取某些信息。他和GET不同的是他只返回首部，而不是实际的资源。所以HEAD一般用于：了解资源的概况（属于哪个种类等），查看资源是否存在以及资源是不是被修改了。如果你用过NGINX或者TENGING，你会发现官网中健康检查的建议使用HEAD。
PUT用于向服务端上传资源，类似数据库中的DDL。
POST用于向服务端输入数据，类似于数据库中的DML。我个人分辨PUT和POST，举个栗子：PUT用来把文件上传到服务器上，而POST用于对文件内容进行更改或者插入或者删除。
TRACE这个方法不太常用，比如我们的实际的生产环境中客户端和服务端中可能用很多中转站，这些中转站会修改我们的报文，如果你想在客户端知道你的报文最终改成什么样了，那就可以用这个方法。
OPTIONS这个方法用于请求服务端告诉客户端支持的功能，类似于咨询的意思。如果你用过跨站请求的话，你会发现在请求前，浏览器会用OPTIONS问一下服务端自己有没有权限访问。
DELETE这个不多说了就是删除资源。
扩展方法HTTP允许我们定义方法。WebDAV HTTP就定义了LOCK，COPY等扩展方法。
状态码
状态码是服务端用于简单描述结果，基本上分为五大类。
100 - 199 这些是比较新的状态码。其中100和101是已经定义好的，100（Continue）用于发送一个服务端无法接受的大文件，客户端会在请求头中带一个100 continue的首部，服务器接收到以后会返回一个100 continue的响应，这样就可以把一个大请求分隔成几个小请求了。101 Switching Protocols, 用于描述把客户端的请求的协议转化为Update首部指出的协议。
200 - 299 这个是大家比较常见的，用于描述请求成功了。

状态码	原因短语	描述
200	OK	请求成功
201	CREATED	资源创建成功
202	ACCEPTED	请求已经接受，但是还没有完成相应的动作

等等还有203 204 205 206大家可以自行百度了
300-399这些是重定向状态码。举个栗子说明什么是重定向：A对B说：把你的钱都给我。B对A说：我不傻，C傻，C会给你。A就去找C了。
有的时候这类状态码也用在验证资源是否更新，比如你本地有个资源副本，你可以发送请求，这个请求中带有资源的描述信息，服务端收到请求后发现资源没有修改，他就回复一个304 NOT Modified,客户端就继续使用本地的副本。

状态码	原因短语	描述
300	Multiple Choices	客户端可能请求的资源包含了多个版本，这样服务端就会回复一个列表让客户端选择
301	Moved Permanently	永久重定向
302	Found	临时重定向
303	See Other	HTTP1.1版本的重定向
307	Temporary Redirect	HTTP1.1版本的临时重定向

400 - 499 客户端错误状态码，比如我们最不喜欢的404就是这类状态码。这类状态码很多，我就不列举了。
500-599服务器错误状态码，用于说明错误是由于服务端的错误引起的。比如500 Internal Server Error。实在不想列举了，写累了，大家自行百度吧。

首部
首部可以说是报文的标签，通过这些标签你就可以快速了解这个报文的属性。比如Content-type: text/plain，你就知道这个报文的实体部分是普通的文本。
大体分为五种类型：
通用首部 这些既可以用在请求中也可以用在返回中使用，比如Date首部就是一个通用的首部用于说明报文发起的时间。
请求首部只能用在请求中，比如Accept首部，用于说明期望服务端返回指定类型的数据
响应首部只能用在响应中，比如Server首部，用于说明服务端的用什么来服务的，nginx或者Django等
实体首部用于描述实体的属性，比如Content-type
扩展首部也就是自定义的首部了。