• 报文流
• 报文的组成部分
  • 报文的语法
  • 起始行
  • 首部
  • 实体的主体部分
  • 版本0.9的报文
• 方法
• 状态码
  • 首部

报文流

• 报文都会向下游流动，所有报文的发送者都在接收者的上游

报文的组成部分

• 报文由三部分组成，起始行，包含属性的首部，可选的包含数据的主体

说明起始行和首部就是由行分隔的ASCII文本，每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符(ASCII 13)和一个换行符(ASCII 10)，这个行终止序列可以写作CRLF；主体部分是可选的，可以是文本或包含二进制数据，也可以为空。

报文的语法

报文分为两类:请求报文，响应报文，通常的请求报文格式是:

  <method> <request-URL> <version>
  <headers>
  <entity-body>

响应报文格式:

  <version> <status> <reason-phrase>
  <headers>
  <entity-body>

简要描述

• method: 客户端希望对服务器资源执行的动作。比如GET/HEAD/POST/PUT，后面会有详解。
• request-URL: 请求资源的完整URL
• version: HTTP 版本 HTTP/<major>.<minor> major:主要版本号，minor:次要版本号，都是整数。
• status: 三位数字描述请求过程中所发生的情况。
• reason-phrase: 原因短语，是开发人员定义的，比如200，定义reason-phrase : NOT OK。
• header: 可以有零个或多个首部，每个首部都包含一个名字后面是(:)然后是可选的空格，接着是值，最后是一个CRLF。
• entity-body: 可选，包含一个由任意数据块组成的数据块。有时，报文只是以一个CRLF结束。

⚠️一组HTTP首部总是应该以CRLF结束，但由于历史原因，很多客户端和服务器在实现主体部分时，都(错误地)省略了最后的CRLF，为了这些流行但不符合规则的实现进行互通，客户端和服务器端都应该接受那些最后没有CRLF的报文。

起始行

1. 请求行
2. 响应行
3. 方法 GET/HEAD/POST/PUT/TRACE/OPTIONS/DELETE
4. 状态码 1XX/2XX/3XX/4XX/5XX
5. 原因短语 对状态码提供的文本形式解释
6. 版本号 HTTP/x.y

首部

• 通用首部 既可以在请求报文中也可以在响应报文中
• 请求首部 提供更多有关请求的信息
• 响应首部 提供更多有关响应的信息
• 实体首部 描述主体的长度和内容，或者资源本身
• 扩展首部 规范中没有定义的新首部

⚠️每个HTTP首部都有个一个简单的语法: 名字后面跟”:”然后是可选空格再跟字段值，最后是一个CRLF，比如Content-length: 12334 , Content-type: image/gif , …..等 首部行分为多行可提高可读性，多出来的每行前面至少要有一个空格或制表符(tab).

实体的主体部分

主体部分就是要传输的内容可承载很多类型的数字数据:图片、视频、HTML文档、软件应用程序、电子邮件等。

版本0.9的报文

HTTP/0.9报文也是由请求和响应组成，但请求中只包含方法和请求URL，响应中只包含实体。没有版本信息(它是第一个，也是当时唯一的版本)，没有状态码或者原因短语，也没有首部。

方法

HTTP定义不产生动作的方法为安全方法，即不会在服务器端产生任何结果，反之不安全。 幂等指的是，请求若干次和请求一次的结果一致，反之非幂等。 详情

• GET 安全幂等
• HEAD 安全幂等,响应只返回首部
• PUT 向服务器写入文档，服务器根据请求URL来命名新文档，如果那个URL已经存在文档，则用当前请求的主体来替代它，因为PUT允许用户对内容进行修改，所以一般Web服务器都需要在执行PUT之前，用密码登陆。不安全，幂等。
• POST 不安全，不幂等
• TRACE 安全幂等
• OPTIONS 请求Web服务器告知其支持的各种功能 安全幂等
• DELETE 请求Web服务器删除请求URL所指定的资源 不安全幂等
• 扩展方法

状态码

• 100 ~ 199 信息性状态码

• 100 Continue 说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后服务器在收到请求之后必须进行响应。
• 101 Switching Protocols 服务器根据客户端的指定，将协议切换成Update首部所列的协议。

• 200 ~ 299 成功状态码

• 300 ~ 399 重定向状态码

⚠️ 302、303、307存在交叉，跟HTTP版本有关系1.0/1.1

• 400 ~ 499 客户端❌状态码

• 500 ~ 599 服务器❌状态码

首部

• 通用首部

通用缓存首部

• 请求首部

1. Acctpt首部(Accept,Accept-Charset,Accept-Encoding,Accept-Language,TE告知服务器可以使用哪些扩展传输编码)
2. 条件请求首部(Expect,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Range)
3. 安全请求首部(Authorization,Cookie,Cookie2)
4. 代理请求首部(Max-Forward与TRACE一同使用,Proxy-Authorization,Proxy-Connection)

• 响应首部 Server: Tiki-Hut/1.0

1. 协商首部(Accept-Ranges:对此资源来说，服务器可以接受的范围类型.Vary:服务器查看的其他首部列表)
2. 安全响应首部(与安全请求首部对应,Proxy-Authenticate,Set-Cookie,Set-Cookie2,WWW-Authenticate来自服务器的对客户端的质询列表)

• 实体首部 Content-Type: text/html; charset=iso-latin-1

1. 内容首部(Content-Base,Content-Encoding,Content-Language,Content-Length,Content-Location,Content-MD5,Content-Range,Content-Type)
2. 实体缓存首部(ETag:与此实体相关的实体标记,Expires:实体不在有效，要从源端再次获取此实体的日期和时间，Last-Modified:实体最后一次被修改的日期和时间)

• 扩展首部 非标准首部，开发者自己创建

⚠️HTTP规范允许服务器在不通知客户端的情况下撤销请求

Wiki HTTP Method HTTP的W3C架构页