Http头信息（一）——通用头信息（二）

已于 2022-12-21 10:47:50 修改
阅读量487 收藏
点赞数
分类专栏： Http 文章标签： http tcp/ip
于 2021-10-17 17:30:20 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_34676644/article/details/120810839
版权

文章目录

介绍

上一篇博文着重介绍了Cache-Control，这篇博文将会介绍剩余的：

  • Connection
  • Date
  • Transfer-Enconding
  • Trailer
  • Upgrade
  • Via
  • Warning

1. Connection

Connection头信息有2个作用，分别是：

  1. 控制不再转发给代理服务器的头信息
  2. 管理持久连接

(1).控制不再转发的头信息

Connection:逐跳首部

什么是逐跳首部？参见：这可能是最全的Http头信息资料了

例如：客户端发送给代理服务器的中头信息中是

GET / HTTP/1.1
Connection:Upgrade
Upgrade:HTTP/1.1
Cache-Control:no-cache

那么代理服务器发送给下一个服务器（可能是代理，也可能是最终服务器）的头信息中就会将Upgrade头信息删除,变成

GET / HTTP/1.1
Cache-Control:no-cache

(2).管理持久连接

<!--关闭连接-->
Connection:close
<!--开启持久连接（适用于Http 1.1之前的版本）-->
Connection:Keep-Alive

在HTTP 1.1版本中，所有的连接默认都是持久连接

持久连接：进行一次Http通讯后，不断开TCP连接

当明确想断开连接时使用Connection:close
在HTTP 1.1之前的版本中，默认都是非持久连接，因此如果要保持持久连接需要指定Connection:Keep-Alive

2.Date

Date指明了创建Http报文的时间
使用的格式有：

  • RFC1123中规定的格式
<!--2021年10月17号，星期天，下午3点08分00秒-->
Date:Sun, 17 Oct 2021 15:08:00 GMT
  • RFC850中规定的格式
<!--2021年10月17号，星期天，下午3点08分00秒-->
Date:Sun, 17-Oct-21 15:08:00 GMT
  • C语言标准库中asctime()的输出格式
<!--2021年10月17号，星期天，下午3点08分00秒-->
Date:Sun Oct 17 15:08:00 2021

3.Transfer-Enconding

该头信息规定了传输报文主体是采用的编码方式。注意和Content-Encoding区分。

  • Transfer-Enconding :在传输过程中使用的编码方式，仅用于两个节点之间的传递，而不是资源本身 [1]。

      例如：源服务器采用了`gzip`传送给了代理服务器，代理服务器解析数据后，将传输方式更改为`chunked`分块传输给客户端

  • Content-Encoding：报文主体采用什么方式编码，整个传输过程中都不会更改

<!--分块传输-->
Transfer-Enconding:chunked
<!--采用 Lempel-Ziv-Welch (LZW) 压缩算法,这种内容编码方式已经被大部分浏览器弃-->
Transfer-Encoding: compress
<!--采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。-->
Transfer-Encoding: deflate
<!--表示采用  Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式-->
Transfer-Encoding: gzip
<!--用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受-->
Transfer-Encoding: identity

分块传输会将实体分成多个部分，每一块都会用十六进制来标记块的大小，而实体的最后一块会使用0(CR+LF)来标记。

对于非持久连接，浏览器可以通过连接是否关闭来界定请求或响应实体的边界；而对于持久连接，这种方法显然不奏效，尽管已经发送完所有数据，但浏览器并不知道这一点，它无法得知这个打开的连接上是否还会有新数据进来，只能傻傻地等
要解决上面这个问题，最容易想到的办法就是计算实体长度，并通过头部告诉对方。这就要用到 Content-Length 了
由于 Content-Length 字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没那么好获得，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。
Transfer-Encoding 正是用来解决上面这个问题的。历史上 Transfer-Encoding 可以有多种取值，为此还引入了一个名为 TE 的头部用来协商采用何种传输编码。但是最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。
分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF(\r\n)，也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束 [2]

例子：

HTTP/1.1 200 OK
...
Content-Encoding:gzip
Transfer-Econding:chunked
...

cf0 <!--转为10进制为：3312-->
... <!--3312字节的内容-->
392 <!--转为10进制为：914-->
... <!--914字节的内容-->
0 <!--分块结束-->

4. Trailer

<!--在报文主体之后还有Date头信息-->
Trailer:Date

该指令指示在报文主体之后还有哪些头信息，不可以包含以下头信息 [3]：

  • 用于信息分帧的首部 (例如Transfer-Encoding 和 Content-Length)
  • 用于路由用途的首部 (例如 Host)
  • 请求修饰首部 (例如控制类和条件类的，如Cache-Control，Max-Forwards，或者 TE)
  • 身份验证首部 (例如 Authorization 或者 Set-Cookie)
  • Content-Encoding, Content-Type, Content-Range，以及 Trailer 自身

可应用于分块传输编码，如：

HTTP/1.1 200 OK
...
Content-Encoding:gzip
Transfer-Econding:chunked
Trailer:Date
...

cf0 <!--转为10进制为：3312-->
... <!--3312字节的内容-->
392 <!--转为10进制为：914-->
... <!--914字节的内容-->
0 <!--分块结束-->

Date:Sun Oct 17 15:08:00 2021

为什么还需要这个字段？直接把头信息放到前面不就好了吗？
这时因为有些信息只有处理完实体内容后才知道。比如一个字节流的大小、消息的完整性验证，消息经过处理后的最终状态等。这时，就需要是使用`Trailer`将信息加到实体的后面

5.Upgrade

询问下一个直连服务器，是否可以使用其他的协议进行通信

<!--询问对方是否可以使用 TLS/1.0或者webSocket协议进行通信-->
Upgrade:TLS/1.0,webSocket

为什么使用`Upgrade`的时候，要配合`Connection:Upgrade`一起使用?

再回到HTTP 1.1的Connection头部，这儿有一个兼容性问题：我们以Upgrade头部为例，某个proxy实现了HTTP 1.0协议，将Upgrade原样转发给后端，后端和proxy升级协议，但是这个情况下，proxy不认识升级后的协议啊 [4]。

如果服务器决定升级这个连接，会返回 101 Switching Protocols状态码，和要切换的协议,如：
客户端发起请求

GET / HTTP/1.1
...
Connection:Upgrade
Upgrade:TLS/1.0,webSocket <!--询问本次通讯是否可以使用`TLS 1.0`或者`webSocket`协议-->
...

服务器给与回应

HTTP/1.1 101 Switching Protocols
...
Upgrade:TLS/1.0 <!--本次通讯可以使用`TLS 1.0`协议-->
...

如果不能使用其他协议，会返回常规的响应，例如：200 OK
注意： 由HTTP/1.1请求建立的连接可以升级为HTTP/2协议的连接，但是反过来不可以。事实上HTTP/2已经不再支持101状态码了，也不再支持任何连接升级机制。[5]

6.Via

<!--
经过的1个代理地址为：p1.example.com，使用的Http协议版本是1.0
经过的2个代理地址为：p1.example.com，使用的Http协议版本是1.1
-->
Via: 1.0 p1.example.com, 1.1 p2.example.net

这个首部由代理服务器添加，每经过一个代理服务器，代理服务器会在Via后面添加一条信息。可以用来追踪消息转发情况

7. Warning

HTTP/1.1的Warning首部是从HTTP/1.0的响应首部Retry-After演变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。
Warning的格式如下：

Warning: <警告码> <警告的主机：端口号> "<警告内容>" [<警告时间>]

警告码[6]

  • 1XX：警告码描述了关于当前响应的新鲜度或者验证状态的警告信息，并且将会在验证之后被缓存服务器删除。
  • 2XX：警告码描述了验证之后不会被修复的某些展现内容方面的警告信息，并且在验证之后不会被缓存服务器删除。

7种警告码

警告码文字描述详细说明
110Response is stale (响应已过期)代理返回的资源已过期
111Revalidate failed (再验证失败)代理再验证资源有效性时失败
112Disconnected Operation（断开链接操作）代理无法连接互联网
113Heuristic Expiration（试探性过期）响应的使用期超过24小时 （有效缓存的设定时间为24小时的情况下）
199Miscellaneous Warning （杂项警告）任意的警告内容
214Transformation Applied（使用了转换）代理返回的展现内容进行了某些处理，比如改变了内容编码、媒体类型等。
299Miscellaneous Warning与199类似，只不过指代的是持久化警告。

下篇文章：Http头信息（二）——请求头信息（一）
关注我，获取最新的更新

Reference

[1]. Transfer-Encoding
[2]. HTTP 协议中的 Transfer-Encoding
[3]. Trailer
[4]. 为什么HTTP Upgrade的时候，需要Connection: upgrade
[5]. 协议升级机制
[6]. Warning

黑森林中的小木屋
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
为什么HTTP Upgrade的时候，需要Connection: upgrade
wukai1211的博客
12-23 5313
很久之前，在看HTTP头部的时候，发现WebSocket等协议的Upgrade请求，需要同时带上Connection和Upgrade头部。但是，如果是仅仅Upgrade的话，Connection头部不就是多余的设计了么？ 比如一个典型的WebSocket升级请求如下： 1 2 3 4 5 6 GET /chat HTTP/1.1 Host: example.com:8000 Upgrade: websocket Connection: Upgrade Sec-WebS
HTTP：协议升级机制（WebSocket）
OceanStar的博客
08-05 1万+
HTTP协议提供了一种特殊的机制，这一机制允许将一个已建立的连接升级成新的、不相容的协议。 通常来说这一机制总是由客户端发起的（不过也有例外，比如说可以由服务端发起升级到传输层安全协议(TLS)），服务端可以选择是否要升级到新协议。借助这一技术，连接可以以常用的协议启动(比如HTTP/1.1)，随后再升级到HTTP2甚至是WebSockets. 注意：HTTP/2 明确禁止使用此机制，这个机制只属于HTTP/1.1 升级HTTP/1.1的链接 协议升级请求总是由客户端发起的；暂时没有服务端请求协议更改的
说说你对HTTP协议中Upgrade头部的理解
最新发布
长风破浪会有时的博客
05-02 263
服务器收到请求后，如果支持WebSockets协议，就会同意升级请求，并返回一个特殊的响应，表示连接已经成功升级成WebSockets连接了。WebSockets协议是一种更高级的协议，它允许我们的电脑和服务器之间建立一个持久的连接，这样我们就可以随时向服务器发送消息，而不需要每次都重新发送HTTP请求。这就像是我们和朋友建立了电话连接，可以随时通话一样。但是，有时候我们想要的不仅仅是一个简单的回信，而是想要和服务器建立一个持久的联系，就像是我们和朋友打电话一样，可以互相发送消息而不需要每次都重新拨号。
HTTP头部信息解释（超级详细）
qq_59736345的博客
05-10 8925
本篇文章将会详细的介绍HTTP头部信息，若大家在使用过程中有不了解的，可以适当参考。若有问题，欢迎随时私聊！！！HTTP头部信息是HTTP协议中的一部分，它包含了HTTP请求和响应的元数据信息。HTTP头部由一组由冒号分隔的键值对组成，每个键值对占一行，每行以回车换行符（\r\n)结束。HTTP头部信息可以包括请求头部和响应头部，它们由不同的作用。
http header 怎么判断协议是不是 websocket
我本可以容忍阳光，如果我不曾见过太阳，然而阳光已使我荒凉，成为更新的荒凉。
05-18 829
点击上方三分钟学前端，关注公众号回复交流，加入前端编程面试算法每日一题群面试官也在看的前端面试资料引言首先，解答本题， http 通过判断 header 中是否包含 Connection...
HTTP协议header头域
perisky的专栏
09-04 739
HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者
Chapi —— 一个通用语言元信息转换器
01-07
上个月底尝试了使用 Antlr 的 Go runtime，但是遇到一系列的挫折加之因为公司内部的一些项目需要类似的工具，我便开始从 JVM 系的语言中寻找一个合适的选择。。 结合疫情的影响，我结束了打苍蝇为乐的休息时间，在...
C++信息奥赛——入门引导 头文件.pdf
11-18
C++信息奥赛——入门引导 头文件 本文档着重介绍C++语言中的头文件，涵盖了头文件的概念、历史发展、分类和使用方法。 头文件的概念 在C++语言中，头文件是一种包含功能函数、数据接口声明的载体文件，主要用于...
通用管理能力综合标准——信息管理
12-16
通用管理能力综合标准——信息管理以实践认知世界，以实事构架世界，通用管理能力综合标准——信息管理...该文档为通用管理能力综合标准——信息管理，是一份很不错的参考资料，具有较高参考价值，感兴趣的可以下载看看
STM32——通用定时器
07-17
STM32中的定时器有多种，按功能分成2个高级控制器定时器，4个普通定时器，2个基本定时器，2个看门狗定时器，1个系统滴答定时器SysTick。
Android常用实例——实现修改用户头像功能
08-20
在Android应用开发中，用户头像是用户个性化表达的一部分，经常在社交、个人信息设置等场景中出现。本实例将深入探讨如何实现一个简单的“修改用户头像”功能，这对于任何涉及用户个人信息的应用都是至关重要的。 ...
浏览器 Upgrade-Insecure-Requests:1 请求头的作用
热门推荐
qq_33019839的博客
09-27 5万+
今天在调试网站时，发现 html 请求头中有个 Upgrade-Insecure-Requests:1 参数，查了一下相关的资料，感觉挺有意思，记录一下。 html Upgrade-Insecure-Requests:1 请求头 HTTP Upgrade-Insecure-Requests 请求头向服务器发送一个客户端对HTTPS加密和认证响应良好，并且可以成功处理的信号，可以请求所属网站所有的H...
Golang http之server源码详解
skh2015java的博客
04-19 1746
http 是典型的 C/S 架构，客户端向服务端发送请求（request），服务端做出应答（response）。HTTP server–简而言之就是一个支持http协议的服务，http是一个相对简单的请求—响应的协议，通常是运行在TCP连接之上， 通过客户端发送请求到服务端，获取服务端的响应。 我们先看一个简单的http server例子 package main...
HTTP：header头总结
OceanStar的博客
08-05 3794
端到端标头：逐跳报头客户端发送请求时，用来指定服务器的域名。有了字段，就可以将请求发往「同一台」服务器上的不同网站。作用：语法： 举例：作用：补充：举例：作用：语法： 补充： 举例：使用流程： 服务器在 Content-Encoding 响应首部提供了实际采用的压缩模式： 需要注意的是，服务器端并不强制要求一定使用何种压缩模式。采用哪种压缩方式高度依赖于服务器端的设置，及其所采用的模块。 Connection字段 作用：语法: close：表明客户端或服务器想要关闭该网络连接，这是HTTP/1.
nginx为项目解析域名！
weixin_42207486的博客
10-17 605
为端口配置域名： server { listen 80; server_name www.*.cn; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $p...
项目调试技巧
weixin_56668422的博客
07-03 333
项目调试技巧
HTTP基础之通用首部字段篇（一）
m0_46405589的博客
07-29 445
HTTP标头 HTTP 1.1的标头主要分为四种，通用标头 、实体标头 、请求标头 、响应标头， 现在我们来对这几种标头进行介绍 通用标头 HTTP通用标头之所以这样命名，是因为与其他三个类别不同，它们不是限定于特定种类的消息或者消息组件(请求，响应或消息实体)的。HTTP通用标头主要用于传达有关消息本身的信息，而不是它所携带的内容。它们提供一般信 息并控制如何处理和处理消息。尽管通用标头不会限定于是请求还是响应报文，但是某些通用标头大部分或全部用于-种特定类型的请求中。也就是说，如果某个通用标头出现在请求
关于HTTP的头connection的事
zt3032的博客
08-04 2364
这个问题主要是想说一下HTTP协议头connection设置的一些问题。 之前就遇到过无论是作为客户端还是服务端出现了端口出现一些不正常的状态(比如：CLOSE_WAIT、CLOSING等)，造成端口不被释放资源浪费，更严重的情况可能会把主机的句柄耗尽导致服务挂起。 讲connection设置之前先说一下，必须对tcp四次分手的过程很熟悉，以下截图是四次分手的各种情况下端口对应的状态值
ISO_IEC_27002
04-28
ISO27002 信息技术-安全技术-信息安全控制实用规则 本标准可作为组织基于 ISO/IEC 27001 实施信息安全管理体系（ISMS）的过程中选择控制措施时的参考，或作为组织实施通用信息安全控制措施时的指南文件。本标准还可以用于开发行业和组织特定的信息安全管理指南，考虑其特定信息安全风险环境

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值