• 作者: 雪山肥鱼
• 时间：20211105 23:45
• 目的: 了解http报文

# 3.1 报文流
# 3.2 报文的组成部分
  ## 3.2.1 报文的语法
  ## 3.2.2 起始行
  ## 3.2.3 首部
  ## 3.2.4 实体的主体部分
# 3.3 方法
  ## 3.3.1 安全方法
  ## 3.3.2 GET
  ## 3.3.3 HEAd
  ## 3.3.4 PUT
  ## 3.3.5 POST
  ## 3.3.6 TRACE
  ## 3.3.7 OPTION
  ## 3.3.8 DELETE
  ## 3.3.9 扩展方法
# 3.4 状态码
  ## 3.4.1 100 ~ 199 信息状态码
  ## 3.4.2 200 ~ 299 成功状态码
  ## 3.4.3 300 ~ 399 重定向状态码
  ## 3.4.4 400 ~ 499 客户端错误状态码
  ## 3.4.5 500 ~ 599 服务器错误状态码
# 3.5 首部
  ## 3.5.1 通用首部
  ## 3.5.2 请求首部
  ## 3.5.3 响应首部
  ## 3.5.4 实体首部

3.1 报文流

http报文是http应用程序之间发送的数据块，这些数据款以一些文本形式的 元信息(meta - information) 开头。

3.2 报文的组成部分

每条报文离不开起始行、首部块、主体三个部分。

image.png

http消息每行都以一个由两个字符组成的终止序列作为结束，其中包括一个回车和一个换行符组成(0d 0a).
终止序列也叫做CRLF. 需要指出:

尽管HTTP规范中说明应该用CRLF来表示行终止，但文件的应用程序也应该接受单个换行符作为行终止，但稳健的应用程序也应该接受单个换行符作为行的终止。因为有些老的，或不完整的http应用程序并不总是既发送回车符，又发送换行符。

实体部分则是一个可选的数据块。主题则可以包含文本或者二进制，当然也可以为空。

3.2.1 报文的语法

image.png

• 请求报文格式
  <method> <request - URL> <version>
  <header>
  <entity-body>

• 响应报文格式
  <version> <status> <reason-phrase>
  <headers>

<entity-body>

各个部分简要描述

• 方法
  客户端希望服务器对资源执行的动作。比如 get head post等

• 请求URL
  请求资源路径

• 版本
  http版本

• 状态码

• 原因短语
  http/1.0 200 ok
  http/1.0 204 no-content
  ok 就是原因短语, no content 也是原因短语

• 首部
  可以有 0 个首部，或者多个首部，后面跟一个冒号(:), 然后一个可选空格，接着一个value，最后一个CRLF。

• 实体部分
  由任意数据组成的数据块。并不是所有报文都包含实体主体部分。

举例.png

3.2.2 起始行

所有http报文都以一个起始行作为开始。请求报文则说明要做说明，响应报文的起始行说明发生了什么。

1. 请求行
   一个方法
   一个请求URL

2. 响应行
   主要是数字状态码，以及原因短语。
   比如状态码为200(表示成功)，原因短语为OK，表示文档已经被成功返回了。

3. 方法

   
   image.png
   

   客户端告诉服务器我要你干嘛

4. 状态码
   状态码告诉客户端发生了什么。

   
   image.png

5. 原因短语
   原因短语与状态码成对出现。

6. 版本号

3.2.3 首部

首部的本质，名/值 的列表。
content-length : 19

• 首部分类

  1. 通用首部
     既可以出现在请求报文，也可以出现在响应报文中
  2. 请求首部
     提供相关请求的信息
  3. 响应首部
     提供相关响应信息
  4. 实体首部
     主题长度和内容，资源自身
  5. 扩展首部
     自定义的

• 首部延续行

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
    Version 1.0

一行太长，回车 tab缩进即可。

3.2.4 实体的主体部分

实体的主体是HTTP报文的符合。就是HTTP要传输的内容。
HTTP报文可以承载很多类型的数字数据:图片、视频、HTML文档等。

3.3 方法

基本的http已经在前方列出。注意 并不是每个服务器都实现了所有方法。而且有些方法是需要权限的。比如 DELETE or PUT 方法。因为 服务器 并不希望任何人能够素以删除或存储资源。这些都是在服务器配置中进行设置的。

3.3.1 安全方法

Get 方法 和 Head 方法被认为是安全的。
因为对于服务器来说不会产生什么动作。意义就似乎不会产生结果。

相对于Post 则会提交一些数据，or 表单 服务器收到后，会做出相应动作，比如把这些数据提交给 网银接口，进行付款等。

3.3.2 Get

从uri 下 拿数据。

Get

3.3.3 HEAD

不要 Get 中的 Body
意义：

1. 在不获取资源的情况下，了解资源情况(判断其类型)
2. 通过查看相应中的状态码，看看某个对象是否存在
3. 通过查看首部，测试资源是否被修改了

3.3.4 PUT

put 会向服务器写入文档。

put.png

put 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，那个URL已经存在的话，就用这个主体替换他。

因为PUT允许用户对内容进行修改，所以很多Web服务器都要求在执行PUT之前，用密码登录

3.3.5 POST

POST.png

Post 方法起初用来向服务器输入数据的。通常会用它来支持HTML表单。表单中填好的数据通常会被送给服务器。服务器将其发送到它要去的地方（比如一个服务器网关程序中，然后由这个程序对其进行处理）。
例子中，客户端向服务器发送查询表单，在响应中返回结果。

3.3.6 TRACE

客户端发起一个请求，这个请求可能要穿过防火墙、代理、网关或其他一些程序，每个中间节点都可能会修改原始的HTTP请求。trace 方法允许客户端在最终将请求发送给服务器时，看看它编程什么样子。
消息行程的最后一站的服务器，会弹回一条trace响应，并在响应体中携带它收到的原始请求报文。（即最后一个网关发出的消息）

image.png

3.3.7 OPTIONS

image.png

告知服务器有哪些方法。

3.3.8 DELETE

告知服务器删除 URI 所指向的指定资源。

image.png

3.3.9 扩展方法

自定义的。

3.4 状态码

3.41. 100 ~ 199 信息类状态码

image.png

1. 客户端与100 Continue
   如果客户端在向服务器发送一个实体，并且愿意在发送实体之前等待100 Continue 响应。那么 客户端就要发送：
   Expect : 100 Continue。
   如果客户端没有发送实体，客户端就不应该发送100 Continue Except 首部，因为这样，会让服务器误以为，客户端要发送一个实体。在死等。

客户端只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用 100 Continue.

其实就是 C 要发给 S 一个 巨包之前，会发一个 Expect:100 Continue，如果服务器发送了 100 continue 的 response，则C 才会发这个巨包。

当然 C 如果没有等到 S 的 100 continue response， 则直接将包发出去。

2. 服务器与 100 Continue
   S 收到一条带有 100 Continue 的 Expect 首部的请求。它会用100 Continue响应或一条错误码来进行响应。

   
   image.png

服务器永远也不应该向没有发送100 Continue 期望的客户端发送 100 Continue的状态码。但有些错误的服务器可能会这么做。

3. 代理与 100 Continue
   如果代理知道下一跳服务器是http/1.1兼容的，或者并不知道下一跳服务器与哪个版本兼容。它都应该将expect 首部向下转发。
   如果代理知道了 下一跳服务器 不兼容 http/1.1以后的version，则直接回复
   417 Expectation failed.

看来 代理维护一些有关下一跳服务器所支持的http版本信息，至少维护最近收到过请求的服务器相关信息，是由好处的。

3.4.2 200 ~ 299 成功码

image.png

3.4.3 300 ~ 399 重定向

重定向：

1. 告诉客户端使用替代位置来访问他们所感兴趣的资源
2. 提供一个替代的响应而不是资源的内容

如果资源已经被移动，可发送一个重定向状态码和一个可选的location首部告诉客户端资源已经被移走，以及现在可以在哪里找到它。
浏览器可以在不打扰使用者的情况下，透明转入新的位置

301.png

由此可见 浏览器帮我们做了不少事的。

可以通过某些重定向状态码对资源的应用程序本地副本与服务器上的进行对比验证。是否为最新的。或是否更改过。
客户端发送了一个特殊的 If - Modified - Since 首部，说明文件是否在1997年10月3日以后被修改过。
没有，则返回304，但并没有返回内容。

image.png

3 开头 到时候看下文档。

3.4.4 400 ~ 499 客户端错误状态码

遇到时查文档

3.4.5 500 ~ 599 服务器错误状态码

遇到时查文档

3.5 首部

首部和方法配合，共同决定了客户端和服务器能做说明事情。

• 通用首部
  C / S 都能用 比如 data
• 请求首部
  Accept: /
• 响应首部
  Server:Tiki-Hut/1.0
• 实体首部
  Content-Type : text/html; charset = iso-latin-l
• 扩展首部
  自定义

3.5.1 通用首部

C/S 都能用
通用缓存首部
http/1.0 引入了 第一个允许 http应用程序缓存对象本地副本的首部。这样就不用每次从服务器获取了。

通用缓存首部.png

3.5.2 请求首部

只有用在请求报文中。说明谁或什么在发送请求、请求源自何处。或者客户端的喜好及能力。

1. accept 首部
   表示能接受什么类型数据
2. 条件请求首部
   有时客户端希望为请求加上某些限制。比如，如果客户端已经由了一份文档副本，就希望只在服务器上的文档与客户端游泳的副本有所区别时，才请求服务器传输文档。这样就可以通过条件请求首部。
3. 安全请求首部
   客户端在获取特定的资源之前，先对自身进行认证。

• Authorization
  包含了客户端提供给服务器，以便对其自身进行认证的数据
• Cookie
  客户端用它向服务器传送一个令牌，它并不是真正的安全首部，但确实隐含了安全功能

4. 代理请求首部

3.5.3 响应首部

image.png

3.5.4 实体首部

实体首部提供了有关实体及其内容的大量信息，从相关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之实体首部可以告知报文的接收者它在对什么进行处理。

image.png

1. 内容首部
   说明其类型尺寸等其他信息

   
   image.png

2. 实体缓存首部
   说明了如何或者什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息。

   
   image.png