为什么 chrome 和 firefox 都只在 https 下请求 zstd 编码的内容

[coolfan]

晚上尝鲜了一下，结果发现请求头里根本就不包含 zstd 。

但是 https 协议的请求头都有 zstd 。

为什么？（我猜一下，是因为兼容性问题吗，使用 http 的可能都是比较老旧的服务？就不要给服务器更多出错的机会了？

顺便试了一下 zstd 的压缩效果

lute.min.js 3.3MB
gzip 556KB
zstd 434KB

[jeesk]

你确定吗？ 我自己测试过在 http 下面 zstd 也可以。

[NewYear]

还需要兼顾 http 么，Edge 的隐身模式都默认无法打开 http 开头的网址了……

早点灭了 http 也好。

[coolfan]

@NewYear 哈哈哈 确实。只是第一次编译 nginx 没注意，ssl 模块需要手动指定才能启用，所以用的 http

[coolfan]

@jeesk 我试了 edge 和 firefox 的最新版本，访问 http 的时候，请求头的 accept-encoding:就只有 gzip, deflate 。http 开头的就是 gzip, deflate, br, zstd也没开隐私模式欸

[jeesk]

手动指定 header zstd ， 看看服务器是否支持再说， 如果不支持就没戏

[savasun]

@coolfan
从客户端普通用户视角来回答：
在 火狐里面 aoout:config 里面有个 security.tls.enable_certificate_compression_zstd 他默认是 true 。 既然有 TLS 了。所以得 HTTP2 了。

从行业规范的角度回答：
你发现 accept-encoding : 的写法顺序是 gzip, deflate, br, zstd 。很明显 不是 按照 字典排序法

各个浏览器社区、厂商团体、是按照
https://datatracker.ietf.org/doc/html/rfc8878 rfc 修订规则的时间先后顺序排序的。
规范规则有了，浏览器才会跟进支持的。
同理可得 在 Http1 时代 gzip rfc 规范早于 rfc8878 。
再同理可得 br 压缩的 rfc7932 要早于 zstd 的 rfc8878
其实 br 和 zstd 0.1 版本几乎是同年出生的。

从服务器应用层角度回答：
Apache httpd 服务器在近期才支持 zstd 压缩 https://github.com/foglede/mod_zstd （满血的可以 http1 支持的）
Ng 也是早前几个月才得到得 zstd 支持（截止到发贴时间，非满血版 security.tls.enable_certificate_compression_zstd = false 就乱码了，http1 支持不完整 ）。

你猜测的是 兼容性问题。 我觉得也有道理，很多 IE6 IE7 IE11 [ gzip ] 不兼容情况也有 HTTP2 用 gzip 的也有乱码的。

所以这多者合力的情况下 导致了 一种错觉 http1 协议状态下没有 zstd 压缩。
——————————————
我最近也在研究这些，参考了很多文献和文档，全部手打的，分享给你，没有无脑问 AI ，AI 回答也没我这么详细。