HTTP报文

HTTP 报文是在 HTTP 应用程序之间发送的数据块（ 用于 HTTP 协议交互的信息）。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。

1、Debug模式下的HTTP事务

URL：https://edu.lagou.com/

Remote Address：访问目标URL解析出来的IP地址，443：表示当前https协议。 

Referrer Policy : Referrer用户指明当前请求的来源页面，对于同源的请求，会发送完整的url作为引用地址，防盗链。

accept：请求可以支持的响应格式列表信息 

accept-encoding：告知服务器本地浏览器支持是压缩方式

sec-fetch-dest：期望获得什么类型的资源

sec-fetch-mode ：navigate，表示这是一个浏览器的页面切换请求

sec-fetch-site：表示一个请求发起的来源和目标资源来源之间的关系，crosssite：跨域请求，same-origin：同源请求。

sec-fetch-user：？1表示的true

upgrade-insecure-requests :1,表示当前浏览器告诉服务器，浏览器是可以处理https请求的，即使访问的https请求中又包含了其他的http请求。

user-agent：描述浏览器的信息 

server ：web应用程序部署的容器，openresty：封装了Nginx以及第三方的类库，Lua语言，redis等等。 

vary ：accept-Encoding，告诉代理服务器缓存两种版本的资源（压缩、不压缩）

2、报文流动

HTTP 使用术语流入（inbound） 和流出（outbound） 来描述事务处理（transaction）的方向。 报文流入源端服务器， 工作完成之后， 会流回用户的 Agent 代理中

报文流入源端服务器并流回到客户端 

3、报文的组成部分

HTTP 报文是简单的格式化数据块。 每条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。 它们由三个部分组成：

1. 对报文进行描述的起始行（start line）
2. 包含属性的首部（header）块
3. 以及可选的包含数据的主体（body） 部分

（1）所有的 HTTP 报文都可以分为两类： 请求报文（request message） 和响应报文（response message）。 请求报文会向 Web 服务器请求一个动作。响应报文会将请求的结果返回给客户端。 请求和响应报文的基本报文结构相同 

这是请求报文的格式：

<method> <request-URL> <version>

<headers>

<entity-body> 

这是响应报文的格式（注意， 只有起始行的语法有所不同） ： 

<version> <status> <reason-phrase>

<headers>

<entity-body>

（2）请求报文

（3）响应报文

（4）HTTP消息由采用ASCII编码的多行文本构成。在HTTP/1.1及早期版本中，这些消息通过连接公开地发送。在HTTP/2中，为了优化和性能方面的改进，曾经可人工阅读的消息被分到多个HTTP帧中。 

Web 开发人员或网站管理员，很少自己手工创建这些原始的HTTP消息︰ 由软件、浏览器、 代理或服务器完成。他们通过配置文件（用于代理服务器或服务器），API （用于浏览器）或其他接口提供HTTP消息。

（5）HTTP 请求和响应具有相似的结构，由以下部分组成︰

1. 一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败，这个起始行总是单行的。
2. 一个可选的HTTP头集合指明请求或描述消息正文。
3. 一个空行指示所有关于请求的元数据已经发送完毕。
4. 一个可选的包含请求相关数据的正文 (比如HTML表单内容)，或者响应相关的文档。 正文的大小有起始行的HTTP头来指定。 

 起始行和 HTTP 消息中的HTTP 头统称为请求头，而其有效负载被称为消息正文。

4、HTTP请求

起始行

HTTP请求是由客户端发出的消息，用来使服务器执行动作。起始行 (start-line)包含三个元素： 

1. 一个 HTTP 方法，一个动词 ([ GET , PUT 或者 POST ) 或者一个名词 (像 HEAD或者 OPTIONS ), 描述要执行的动作. 例如, GET 表示要获取资源， POST 表示向服务器推送数据 (创建或修改资源)。

2. 请求目标 (request target)，通常是一个URL，或者是协议、端口和域名的绝对路径，通常以请求的环境为特征。请求的格式因不同的 HTTP 方法而异。它可以是：

• 一个完整的URL，被称为 绝对形式 (absolute form)，主要在使用 GET方法连接到代理时使用。

  GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

• 由域名和可选端口（以':' 为前缀）组成的 URL 的 authoritycomponent，称为 authority form。 仅在使用 CONNECT 建立 HTTP 隧道时才使用。 

  CONNECT developer.mozilla.org:80 HTTP/1.1

• 星号形式 (asterisk form)，一个简单的星号( '*' )，配合 OPTIONS 方法使用，代表整个服务器。 

  OPTIONS * HTTP/1.1

3. HTTP 版本 (HTTP version)，定义了剩余报文的结构，作为对期望的响应版本的指示符。

Headers

来自请求的 HTTP headers遵循和 HTTP header 相同的基本结构：不区分大小写的字符串，紧跟着的冒号 (':') 和一个结构取决于 header 的值。 整个header（包括值）由一行组成，这一行可以相当长。 

Body

请求的最后一部分是它的 body。不是所有的请求都有一个 body：例如获取资源的请求，GET，HEAD，DELETE 和 OPTIONS，通常它们不需要 body。 有些请求将数据发送到服务器以便更新数据：常见的的情况是 POST 请求（包含HTML 表单数据）。

5、HTTP响应

状态行

HTTP 响应的起始行被称作 状态行 (status line)，包含以下信息：

• 协议版本，通常为 HTTP/1.1。
• 状态码 (status code)，表明请求是成功或失败。常见的状态码是 200 ，404 ，或 302 。
• 状态文本 (status text)。一个简短的，纯粹的信息，通过状态码的文本描述，帮助人们理解该 HTTP 消息。

一个典型的状态行看起来像这样： HTTP/1.1 404 Not Found 。

Headers

响应的 HTTP headers：不区分大小写的字符串，紧跟着的冒号 ( ':' ) 和一个结构取决于 header 类型的值。 整个 header（包括其值）表现为单行形式。

Body

响应的最后一部分是 body。不是所有的响应都有 body。

6、HTTP请求方法

请求的起始行以方法作为开始， 方法用来告知服务器要做些什么。

GET

GET 是最常用的方法。 通常用于请求服务器发送某个资源。 HTTP/1.1 要求服务器实现此方法。 

HEAD

HEAD 方法与 GET 方法的行为很类似， 但服务器在响应中只返回首部。 不会返回实体的主体部分。 这就允许客户端在未获取实际资源的情况下， 对资源的首部进行检查。 使用 HEAD， 可以： 

• 在不获取资源的情况下了解资源的情况（比如， 判断其类型） ；
• 通过查看响应中的状态码， 看看某个对象是否存在；
• 通过查看首部， 测试资源是否被修改了。

服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。 遵循HTTP/1.1 规范， 就必须实现 HEAD 方法。

PUT

与 GET 从服务器读取文档相反， PUT 方法会向服务器写入（更新）文档。

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

POST

POST 方法起初是用来向服务器输入数据的 。 实际上， 通常会用它来支持HTML的表单。 表单中填好的数据通常会被送给服务器处理。

TRACE

TRACE客户端发起一个请求时， 这个请求可能要穿过防火墙、 代理、 网关或其他一些应用程序。 每个中间节点都可能会修改原始的 HTTP 请求。 TRACE 方法允许客户端在最终将请求发送给服务器时， 看看它变成了什么样子。TRACE 请求会在目的服务器端发起一个“环回” 诊断。 行程最后一站的服务器会弹回一条TRACE 响应， 并在响应主体中携带它收到的原始请求报文。 这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上， 原始报文是否， 以及如何被毁坏或修改过 

TRACE 方法主要用于诊断； 也就是说， 用于验证请求是否如愿穿过了请求 / 响应链。 

OPTIONS

OPTIONS 方法请求 Web 服务器告知其支持的各种功能。 可以询问服务器通常支持哪些方法， 或者对某些特殊资源支持哪些方法。

DELETE

DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。

7、状态码 

方法是用来告诉服务器做什么事情的， 状态码则用来告诉客户端，事情执行的结果。状态码位于响应的起始行中。 服务器通常会返回一个数字状态和一个可读的状态。 数字码便于程序进行差错处理， 而原因短语则更便于人们理解。

• 200 到 299 之间的状态码表示成功。
• 300 到 399 之间的代码表示资源已经被移走
• 400 到 499 之间的代码表示客户端的请求出错
• 500 到 599 之间的代码表示服务器出错

状态码分类：

常见状态码： 

成功状态码

客户端发起请求时， 这些请求通常都是成功的。 服务器有一组用来表示成功的状态码， 分别对应于不同类型的请求。 

重定向状态码

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源， 要么就提供一个替代的响应而不是资源的内容。 

如果资源已被移动， 可发送一个重定向状态码告知客户端资源已被移走， 以及现在可以在哪里找到目标资源。

使用场景：

web应用支持https，客户端访问http://edu.lagou.com，服务器收到请求之后（Nginx）发现请求的是http请求，可以返回301告知浏览器重新发出请求。 

重定向状态码与原因短语：

• 301 redirect: 301 代表永久性转移(Permanently Moved)
• 302 redirect: 302 代表暂时性转移(Temporarily Moved )

 301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。

他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。

客户端错误状态码 

有时客户端会发送一些服务器无法处理的东西， 比如格式错误的请求报文， 或者最常见的是， 请求一个不存在的 URL。浏览网页时， 我们都看到过臭名昭著的 404 Not Found 错误码——这只是服务器在告诉我们， 它对我们请求的资源一无所知。 

服务器错误状态码

有时客户端发送了一条有效请求， 服务器自身却出错了。 这可能是客户端碰上了服务器的缺陷， 或者服务器上的子元素， 比如某个网关资源， 出了错。代理尝试着代表客户端与服务器进行交流时， 经常会出现问题。 

最后

以上就是苹果白云为你收集整理的HTTP报文的全部内容，希望文章能够帮你解决HTTP报文所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。