报文流
HTTP报文在客户端、服务器和代理之间流动。“流入”、“流出”、“上游”、“下游”这些术语用来描述报文方向。
报文流入源端服务器
流入：流向服务器
流出：流向用户Agent代理
报文向下游流动
所有报文都会向下游流动。对请求报文来说，客户端在服务器的上游；而对于响应报文来说，服务器在客户端的上游。
报文的组成部分
三个部分：对报文进行描述的起始行、包含属性的首部块、包含数据的主体（可选）。
起始行和首部是由行分隔的ASCII文本。每行以一个由两个字符组成的行终止符序列作为结束，包括一个回车符和一个换行符。这个行终止序列可以写作CRLF。
报文的语法
请求报文的格式：
<method><request-URL><version><headers><entity-body>
响应报文的格式：
<version><status><reason-phrase><headers><entity-body>
PS：一组HTTP首部总是应该以一个空行（仅有CRLF）结束，甚至没有首部和实体的主体部分也应该如此。
起始行
请求报文：要做些什么；响应报文：发生了什么。
方法
请求的起始行以方法作为开始
状态码
状态码告诉客户端发生了什么事情，位于响应行的起始行中。
原因短语
响应起始行最后。为状态码提供了文本形式的解释。
版本号
说明了应用程序支持的最高HTTP版本。
PS：版本号不会当做小数来处理，每个数字当作一个单独的数字来处理。如HTTP/2.22比HTTP/2.3的版本高。
首部
名/值对的列表（后面具体介绍）
实体的主体部分
图片、视频、HTML文档等等等等。
版本0.9的报文
请求中只有方法和请求URL，响应中只包含实体。
方法
安全方法
GET和HEAD都认为是安全方法，不会产生动作，意味着HTTP请求不会再服务器上产生什么结果。
GET方法
用于请求服务器发送某个资源。
HEAD
与GET方法类似，但服务器在响应中只返回首部，不会返回实体的主体部分。
● 在不获取资源的情况下了解资源的情况
● 查看响应中的状态码看看某个对象是否存在
● 测试资源是否被修改了
PUT方法会向服务器写入文档。很多Web服务器要求在执行PUT之前用密码登录。
POST
起初是用来向服务器输入数据的。通常会用它来支持HTML的表单。
TRACE 客户端在发送请求时，可能要穿过防火墙、代理、网关或其他一些应用程序，每个中间节点都可能会修改原始的HTTP请求，TRACE方法允许客户端在最终把请求发送给服务器时看看它变成了什么样子。
缺点：它假定中间应用程序对不同类型请求的处理是相同的。然而很多应用程序会根据方法的不同做出不同的事情，TRACE不提供区分这些方法的机制。
OPTIONS
请求Web服务器告知其支持的各种功能。
DELETE
请服务器删除URL指定的资源。但是客户端无法保证删除操作一定被执行。
扩展方法
没有在HTTP/1.1规范中定义的方法。“对所发送的内容要求严一点，对所接收的内容宽容一些”。
状态码
100~199——信息状态码
100：收到了请求的初始部分，晴客户端继续。
200~299——成功状态码
200：请求没问题
204：响应报文中包含若干首部和一个状态行，但没有实体的主体部分
206：成功执行了一个部分或范围请求
300~399——重定向状态码
304：Not Modified
400~499——客户端错误状态码
400：客户端发送了一个错误的请求
404：Not Found
500~599——服务器错误状态码
500：服务遇到一个妨碍它为请求提供服务的错误
502：作为代理或网关使用的服务器收到了一条伪响应
首部
● 通用首部
客户端和服务器都可以使用的通用首部
● 请求首部
● 响应首部
● 实体首部
● 扩展首部
通用首部
通用缓存首部
请求首部
1.Accept首部
将客户端喜好和能力告知服务器
2.条件请求首部
为请求加上某些限制
3.安全请求首部
对请求进行质询/响应认证
4.代理请求首部
响应首部
1.协商首部
2.安全响应首部
实体首部
1.内容首部
2.实体缓存首部
