- 综合排序
- 最热优先
- 最新优先
- 来自专栏PT运维技术
CDN故障案例content-encoding深入分析
故障现象: 同事反映在AWS的s3增加自定义header: Content-Encoding:gzip后，通过AWS 的cdn(cloudfront)加速后，chrome浏览器发现无法打开。 仔细查看报错的字符:content_decoded_fail, 初步判断是由于gzip压缩导致的问题，在S3 资源文件中去掉Content-Encoding:gzip自定义header后，cloudfront 如果upstream返回的数据的包 头字段中必定含有: "Content-Encoding: gzip" 字段， 那么上面的 r→headers_out.content_encoding判断为真，nginx 到此，自定义header "Content-Encoding: gzip" 导致chrome报错的原因算是定位到了：由于源站没有开启gzip, cdn回源的时候返回的是非压缩的数据，但是添加了自定义了 变化 压缩请求response的Etag,content-encoding变化 CDN的缓存规则: proxy_cache_key hosturiis_argsargs, CDN完全透传请求头到源站(
2.9K20编辑于 2022-06-14 - 来自专栏全栈程序员必看
## HTTP系列之Accept-Encoding和Content-Encoding
优化的方式也不一而足，今天重点不在于介绍性能优化，而是介绍性能优化的其中一种方式，通过压缩来节省http请求的流量，实现过程中依赖http中header部分的两个字段，Accept-Encoding和Content-EnCoding 首先我们先了解下Accept-Encoding和Content-Encoding的作用。 含义与作用 为什么首先要讲这两个字段的含义呢？ ，并且从header里拿到编码标识时，就可以选择其中一种方式来进行编码压缩，然后返给客户端，但是如果response的header里没有编码标识的话，客户端就不知道服务端是用的哪种方式压缩的，所以需要Content-Encoding Content-Encoding用来标识主体进行了何种方式的内容编码转换。 node中的使用 项目中使用的node实现的ssr，因此重要讨论下在node中实现压缩来完成性能的优化。 bgzip\b/)){ zlib.gzip(body,function(err,data){ if(err){ //...错误处理逻辑 } res.setHeader('content-encoding
2.6K30编辑于 2022-09-14 - 来自专栏nginx
深入理解HTTP头中的Accept-Encoding与Content-Encoding
Content-Encoding: 服务器通过这个头字段告诉客户端，返回的数据使用了哪种压缩算法。 2. Content-Encoding头字段 3.1 定义与作用 Content-Encoding是HTTP响应头中的一个字段，服务器通过它告诉客户端返回的数据使用了哪种压缩算法。 例如： HTTP/1.1 200 OK Content-Encoding: gzip Content-Length: 1234 [压缩后的数据] 4.3 客户端解压缩 客户端在接收到响应后，会根据Content-Encoding 例如，如果Content-Encoding为gzip，客户端会使用gzip算法对数据进行解压缩。 5. 总结 Accept-Encoding和Content-Encoding是HTTP协议中用于数据压缩的两个重要头字段。
52710编辑于 2025-11-15 - 来自专栏全栈程序员必看
HTTP中的Accept-Encoding、Content-Encoding、Transfer-Encoding、Content-Type
Accept-Encoding和Content-Encoding Accept-Encoding和Content-Encoding是HTTP中用来对采用何种压缩格式传输正文进行协定的一对header。 工作原理如下： 浏览器发送请求，通过Accept-Encoding带上自己支持的内容编码格式列表 服务端从中挑选一个用来对正文进行编码，并通过Content-Encoding响应头指明响应编码格式。 浏览器拿到响应正文后，根据Content-Encoding进行解压缩。服务端若响应未压缩的正文，则不允许返回Content-Encoding。 : gzip' -X POST https://qgy18.com/node/ Transfer-Encoding与Content-Encoding的区别： Transfer-Encoding只是在传输过程中才有的 Transfer-Encoding是一个”跳到跳”的header，而Content-Encoding是”端到端”的header。
5.4K20编辑于 2022-09-07 - 来自专栏分享学习
OkHttp接受response返回的gzip压缩数据时的坑
公众号:知识浅谈 众所周知，在 HTTP 传输时是支持 gzip 压缩的，客户端发起请求时在请求头里增加 Accept-Encoding: gzip，服务端响应时在返回的头信息里增加 Content-Encoding 的这些语句中会判断返回的如果返回的数据类型是gzip并且我们请求头中没有设置上边的accept-encoding的话，会自动进行解压，但是当我们添加了请求头就不自动解压了，具体代码如下 //如果返回的头信息里Content-Encoding ，则会进行 gzip 解压数据流 if (transparentGzip && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding source()); Headers strippedHeaders = networkResponse.headers().newBuilder() .removeAll("Content-Encoding ，则会进行 gzip 解压数据流 if (transparentGzip && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding
4.5K10编辑于 2022-05-16 - 来自专栏IMWeb前端团队
Nodejs进阶：Express常用中间件body-parser实现解析
POST /test HTTP/1.1 Host: 127.0.0.1:3000 Content-Type: text/plain; charset=utf8 Content-Encoding: gzip chyingp 其中需要我们注意的有Content-Type、Content-Encoding以及报文主体： Content-Type：请求报文主体的类型、编码。 Content-Encoding：声明报文主体的压缩格式，常见的取值有gzip、deflate、identity。 报文主体：这里是个普通的文本字符串chyingp。 path: '/test', method: 'POST', headers: { 'Content-Type': 'text/plain', 'Content-Encoding 客户端代码如下，要点如下： 压缩类型声明：Content-Encoding赋值为gzip。 请求体压缩：通过zlib模块对请求体进行gzip压缩。
1.3K100发布于 2017-12-29 - 来自专栏nginx
深入解析GZIP解压缩异常：从错误日志到解决方案
服务端在接收到请求后，会根据 Content-Encoding: gzip 头自动解压缩数据，然后进行业务处理。 问题分析 2.1 错误发生的代码位置 在 RequestAdController.mediaAd2 方法中，服务端首先检查请求头是否包含 Content-Encoding: gzip，如果是，则调用 decompress ") && Objects.requireNonNull(headers.get("Content-Encoding")).contains("gzip")) { 解决方案 3.1 客户端修复 客户端应确保： 只有在真正压缩数据时才设置 Content-Encoding: gzip。 总结 本次问题是由于 客户端错误地设置了 Content-Encoding: gzip 但未真正压缩数据，导致服务端解压缩失败。通过以下方式解决： 客户端修复：确保正确压缩数据。
27810编辑于 2025-11-15 - 来自专栏个人教程
Java中HTTP请求返回乱码 - GZIP压缩问题
思路 使用了GZIP压缩的数据在响应头里会有一项名为content-encoding的参数，值为gzip。 Java中可以使用.getHeaderField()读取响应头的参数。 解决方法 用.getHeaderField("content-encoding")读取content-encoding参数的值。 如果值不为空，通过值判断是否用了gzip压缩。 代码 关键部分 // 获取响应头content-encoding数据，如果是gzip就解压（以后可能要改成部分对比.contains()而不是全部对比） String contentEncoding = conn.getHeaderField("content-encoding"); if((contentEncoding ! gzip就解压（以后可能要改成部分对比.contains()而不是全部对比） String contentEncoding = conn.getHeaderField("content-encoding
6K41编辑于 2022-06-15 - 来自专栏IMWeb前端团队
Nodejs进阶：Express常用中间件body-parser实现解析
POST /test HTTP/1.1 Host: 127.0.0.1:3000 Content-Type: text/plain; charset=utf8 Content-Encoding: gzip chyingp 其中需要我们注意的有Content-Type、Content-Encoding以及报文主体： Content-Type：请求报文主体的类型、编码。 Content-Encoding：声明报文主体的压缩格式，常见的取值有gzip、deflate、identity。 报文主体：这里是个普通的文本字符串chyingp。 path: '/test', method: 'POST', headers: { 'Content-Type': 'text/plain', 'Content-Encoding 客户端代码如下，要点如下： 压缩类型声明：Content-Encoding赋值为gzip。 请求体压缩：通过zlib模块对请求体进行gzip压缩。
1.5K20发布于 2019-12-03 - 来自专栏前端劝退师
「简明性能优化」双端开启Gzip指南
服务端发送数据时可以配置 Content-Encoding：gzip，用户说明数据的压缩方式 客户端接受到数据后去检查对应字段的信息，就可以根据相应的格式去解码。 在 http／1.0 协议中关于服务端发送的数据可以配置一个 Content-Encoding 字段，这个字段用于说明数据的压缩方法 Content-Encoding: gzip Content-Encoding : compress Content-Encoding: deflate 客户端在接受到返回的数据后去检查对应字段的信息，然后根据对应的格式去做相应的解码。 可以看 Network，但这里我更推荐用 curl: 通过使用 curl测试每个资源的请求响应，并检查 Content-Encoding： ? 显示 Content-Encoding:gzip，即为配置成功。 5. 双端Gzip区别详解 不同之处在于： Webpack压缩会在构建运行期间一次压缩文件，然后将这些压缩版本保存到磁盘。
1.9K30发布于 2019-09-17 - 来自专栏笔耕不辍
程序解码错误-由python的requests.post 请求结果乱码引起的思考
': 'br' }里面的{'Content-Encoding': 'br'} 这个引起了我的注意。 Content-Encoding与Accept-Encoding的说明当设置压缩格式后，服务器会根据用户设置的压缩格式对页面进行压缩，节省http请求的流量。 当response的header里没有编码标识的话，客户端就不知道服务端是用的哪种方式压缩的，所以需要Content-Encoding来标识服务端压缩时所用的压缩方式。 Content-Encoding：用来标识主体进行了何种方式的内容编码转换。 当没有Content-Encoding header时， 就默认为这种情况到这里，问题就彻底明了了，因为Content-Encoding设置的是“br”算法，但是客户端不支持br算法，所以，导致了乱码的现象
2.4K60编辑于 2023-02-14 - 来自专栏彭湖湾的编程世界
【Node.js】 bodyparser实现原理解析
Buffer对象，将其放到一个命名为chunks的数组中 在request的end事件触发时，通过Buffer.concat(chunks)将Buffer数组整合成单一的大的Buffer对象 解析请求首部的Content-Encoding application/x-www-form-urlencoded'对4中得到的字符串做相应的解析处理，得到最后的对象，作为request.body返回 下面展示下相关的代码 整体代码结构 // 根据Content-Encoding const encode = req.headers['content-encoding']; // 获取content-type 进行解压处理 Content-Encoding可分为四种值：gzip，compress，deflate，br，identity 其中 identity表示数据保持原样，没有经过压缩 compress已经被大多数浏览器废弃 Q2：为什么要对content-encoding做处理呢？ 一般情况下我们认为，考虑到前端发的AJAX之类的请求的数据量，是不需要做Gzip压缩的。
2.4K20发布于 2019-09-29 - 来自专栏YuanXin
NodeJS模块研究 - zlib
rs.pipe(gunzip).pipe(ws); HTTP 中的压缩/解压 在服务器中和客户端的传输过程中，浏览器（客户端）通过 Accept-Encoding 消息头来告诉服务端接受的压缩编码，服务器通过 Content-Encoding } // 匹配支持的压缩格式 if (/\bdeflate\b/.test(acceptEncoding)) { res.writeHead(200, { "Content-Encoding zlib.createDeflate()).pipe(res); } else if (/\bgzip\b/.test(acceptEncoding)) { res.writeHead(200, { "Content-Encoding zlib.createGzip()).pipe(res); } else if (/\bbr\b/.test(acceptEncoding)) { res.writeHead(200, { "Content-Encoding { const output = fs.createWriteStream("example.com_index.html"); switch (response.headers["content-encoding
2K31发布于 2020-04-21 - 来自专栏JAVA乐园
SpringBoot 压缩数据流如何解压
客户端发送请求，服务端压缩响应数据返给客户端 客户端请求中增加 Accept-Encoding: gzip 表示客户端支持gzip； 服务端接收到请求后，将结果通过 gzip 压缩后返回给客户端并在响应头中增加 Content-Encoding : gzip 表示响应数据已被压缩 客户端接收请求，响应头中有 Content-Encoding: gzip 表示数据需解压处理 客户端也可以发送压缩数据给服务端，通过代码将请求数据压缩即可，规范起见同样要在请求中加入 Content-Encoding: gzip 0x02：SpringBoot 案例 pom.xml 引入如下依赖 <project xmlns="http://maven.apache.org/POM { super(request); this.request = request; } /** * 根据 request header 的 <em>Content-Encoding</em> Request compressedRequest = originalRequest.newBuilder() .header("Content-Encoding
1.7K50发布于 2021-07-22 - 来自专栏Linyb极客之路
记一次springcloud gateway记录日志响应结果乱码问题
如果服务器选择了一种内容编码方式，它会在响应头部的 Content-Encoding 字段中指定所使用的编码方式。 去掉这个头信息就是告诉服务器，客户端不支持压缩，要求不压缩直接返回数据 另外一种思路是如果服务器选择了一种内容编码方式，它会在响应头部的 Content-Encoding 字段中指定所使用的编码方式。 因此我们就可以根据Content-Encoding来判断是否要对数据进行解压缩 网关日志记录过滤器核心改造的示例如下 /** * 记录响应日志 * 通过 DataBufferFactory encodingList) && encodingList.contains(GZIP); } return false; } 注： 特别提醒，因为要获取服务端header响应Content-Encoding 另外一种如果不移除Accept-Encoding，就得根据Content-Encoding来对服务端响应的数据进行解压缩
53810编辑于 2025-01-19 - 来自专栏移动开发面面观
okhttp——BridgeInterceptor
.request(userRequest) if (transparentGzip && "gzip".equals(networkResponse.header("Content-Encoding responseBody.source()) val strippedHeaders = networkResponse.headers().newBuilder() .removeAll("Content-Encoding responseBuilder.build() } 如果Response是gzip模式且transparentGzip为true且HttpHeaders.hasBody为true时，会去掉Headers中的"Content-Encoding response.header("Transfer-Encoding"))) { return true; } return false; } 所以，okhttp会去掉Headers中的"Content-Encoding "和"Content-Length"的条件是： 用户未设置Request的"Accept-Encoding" 用户未设置Request的"Range" Response中"Content-Encoding
1.6K30发布于 2019-05-15 - 来自专栏用户8281292的专栏
如何通过gzip和nginx来提高网站打开速度及整体性能
text/html Last-Modified: Tue, 09 Feb 2021 19:03:41 GMT Connection: keep-alive ETag: W/"6022dc8d-400" Content-Encoding : gzip 在最后一行，出现Content-Encoding: gzip字样。 09 Feb 2021 19:03:45 GMT Connection: keep-alive ETag: "6022dc91-400" Accept-Ranges: bytes 输出结果中没有出现Content-Encoding curl -H "Accept-Encoding: gzip" -I http://localhost/test.css 结果一样，没有出现Content-Encoding: gzip Output HTTP : Tue, 09 Feb 2021 19:03:45 GMT Connection: keep-alive Vary: Accept-Encoding ETag: W/"6022dc91-400" Content-Encoding
1.7K20发布于 2021-03-18 - 来自专栏Linyb极客之路
记一次springcloud gateway记录日志响应结果乱码问题
如果服务器选择了一种内容编码方式，它会在响应头部的 Content-Encoding 字段中指定所使用的编码方式。 去掉这个头信息就是告诉服务器，客户端不支持压缩，要求不压缩直接返回数据另外一种思路是如果服务器选择了一种内容编码方式，它会在响应头部的 Content-Encoding 字段中指定所使用的编码方式。 因此我们就可以根据Content-Encoding来判断是否要对数据进行解压缩网关日志记录过滤器核心改造的示例如下 /** * 记录响应日志 * 通过 DataBufferFactory encodingList) && encodingList.contains(GZIP); } return false; }注： 特别提醒，因为要获取服务端header响应Content-Encoding 另外一种如果不移除Accept-Encoding，就得根据Content-Encoding来对服务端响应的数据进行解压缩
60310编辑于 2025-01-14 - 来自专栏IMWeb前端团队
Node基础：资源压缩之zlib
=-1){ // 判断是否需要gzip压缩 gzip = zlib.createGzip(); // 记得响应 Content-Encoding，告诉浏览器：文件被 gzip 压缩过 res.writeHead(200, { 'Content-Encoding': 'gzip' }); fs.createReadStream =-1){ res.writeHead(200, { 'content-encoding': 'gzip' }); res.end
2.1K80发布于 2018-01-08 - 来自专栏黄希彤的专栏
用SCF云函数输出gzip/deflate压缩过的数据，以及API网关的Bug
Content-Type":"text/json; charset=utf-8", 'Access-Control-Allow-Origin:':'*', 'Content-Encoding Content-Type":"text/json; charset=utf-8", 'Access-Control-Allow-Origin:':'*', 'Content-Encoding 这本来是一个很方便的好事，但是这次API网关的升级却带来了几个新的bug：1 响应压缩无法关闭，唯一的关闭方式是自己声明content-encoding。 而按照http协议，唯一允许声明content-encoding的情况是压缩，所以如果按照协议实现的话就还是无法关闭压缩，除非丢开协议不管了自己耍流氓声明个自定义的编码方式。
1.1K101编辑于 2022-08-22
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号