手动解析HTTP响应与PNG结构：从字节流到Canvas渲染

1. 这不是教科书里的HTTP而是你真正能“看见”的响应流“一步一步解析HTTP响应报文并解析显示PNG图片”——这个标题乍看像实验室作业但其实它直击一个被多数人忽略的真相我们每天刷网页、传文件、调接口却极少真正“看见”数据是怎么从服务器一帧一帧抵达浏览器的。这不是理论题是实操题不是学完就忘的概念而是你调试接口失败时、图片加载空白时、抓包工具里一堆乱码时最该立刻调出来的救命技能。我带过不少刚入行的开发者他们能写React组件、能配Nginx反向代理但当后端返回一张PNG却在前端白屏第一反应是“是不是React没渲染好”而不是“先看看原始响应体有没有被截断、Content-Type对不对、Transfer-Encoding有没有干扰解码”。这中间差的就是对HTTP响应报文结构的肌肉记忆。而PNG图片恰恰是最理想的切入点它有明确的文件头魔数89 50 4E 47有可验证的IHDR块结构有严格的校验逻辑CRC且不依赖JavaScript渲染引擎——你用最原始的字节操作就能确认它是否完整、是否合法。这个项目不依赖任何框架不调用fetch或axios的高层封装而是从TCP连接建立后的第一个字节开始逐层剥离状态行、响应头、空行、响应体再把二进制流按PNG规范切片、校验、提取宽高与颜色类型最后用Canvas或Blob URL真实呈现出来。它解决的不是“怎么发请求”而是“当请求回来你怎么确信它真的回来了且没被篡改、没被截断、没被误解析”。适合三类人前端工程师想夯实网络基础、后端开发者需验证自己构造的响应是否合规、安全/测试人员要手动验证HTTP传输完整性。你不需要懂密码学但得愿意打开十六进制编辑器盯着0x89和0x00一行行比对。2. 整体设计思路为什么必须“手动拆解”而不是直接用Image.src2.1 核心矛盾抽象层掩盖了关键故障点现代前端开发中加载一张PNG只需一行代码img.src https://example.com/logo.png。浏览器自动处理DNS、TCP握手、HTTP请求发送、响应接收、MIME类型识别、解码、渲染。这种便利性是双刃剑——当图片不显示时错误可能发生在任意一层DNS解析失败、TLS证书过期、服务器返回了302重定向但Location头缺失、Content-Length与实际体长不符导致截断、响应头里Content-Type: text/plain却塞了二进制PNG数据、甚至CDN缓存了损坏的响应体。而所有这些在img.onerror回调里只体现为一个模糊的“加载失败”。手动解析HTTP响应报文本质是主动降级到协议层绕过浏览器的自动修复与容错机制强制自己面对原始字节。这不是为了炫技而是构建一套可验证、可审计、可复现的诊断链路。比如当你手动解析出响应头中的Content-Length: 12480再用Uint8Array读取全部12480字节最后用PNG规范验证其IDAT块CRC校验值——如果校验失败问题一定出在网络传输或服务器生成环节如果校验通过但Canvas显示黑屏则问题在JS解码逻辑或Canvas上下文配置。这种因果链条是高层API永远无法提供的。2.2 方案选型Node.js vs 浏览器原生Fetch为什么最终选纯浏览器TypedArray最初考虑过Node.js方案用http模块发起请求监听response事件获取res.rawHeaders和res的ReadableStream再用pngjs库解析。但很快发现两个硬伤一是Node.js环境无法直接操作DOM和Canvas演示“显示PNG”环节需额外起HTTP服务或转Base64增加复杂度二是Node.js的http模块默认会自动处理gzip解压缩、chunked编码你看到的res已经是解码后的干净字节流失去了观察原始HTTP分块传输Chunked Transfer Encoding的机会。转回浏览器环境后又面临选择用fetch()还是XMLHttpRequestfetch()更现代但其Response.body返回的是ReadableStream需用stream.getReader()逐块读取而HTTP响应报文的关键特征——如状态行与响应头之间的\r\n\r\n空行位置、Transfer-Encoding: chunked的分块边界——在流式读取中极易被跨块切割导致解析逻辑崩溃。XMLHttpRequest虽略显陈旧但其responseType: arraybuffer能一次性获取完整响应体配合xhr.getAllResponseHeaders()获取原始头信息完美匹配“先收全、再解析”的设计目标。更重要的是XMLHttpRequest的status和statusText属性直接暴露状态行无需手动解析。因此最终技术栈锁定为纯浏览器环境 XMLHttpRequest Uint8Array DataView Canvas API。零外部依赖所有代码可直接粘贴进Chrome控制台运行且能清晰展示每一步的原始字节与结构映射。2.3 PNG解析为何不能跳过直接用URL.createObjectURL行不行有人会问既然最终要显示图片为什么不直接用URL.createObjectURL(new Blob([responseArrayBuffer], {type: image/png}))这确实能绕过解析但彻底丧失了“验证”价值。createObjectURL会将任意二进制数据交给浏览器内置解码器而浏览器对PNG有极强的容错能力——即使文件头魔数错误、IHDR块长度不对、CRC校验失败它仍可能尝试“尽力渲染”给出一张扭曲或部分缺失的图。这让你误以为数据完整实则已损坏。手动解析PNG核心在于执行三项不可绕过的校验魔数校验检查前8字节是否为89 50 4E 47 0D 0A 1A 0APNG signature这是文件合法性的第一道门槛IHDR块解析定位第一个IHDR块PNG必须以IHDR开头读取其4字节宽度、4字节高度、1字节位深度、1字节颜色类型、1字节压缩方法、1字节滤波方法、1字节互交错标志并验证该块的CRC校验值基于块类型数据计算IDAT块聚合与CRC校验收集所有IDAT块的数据拼接成完整的图像数据流并对每个IDAT块单独校验CRC确保传输无误。只有这三步全部通过才能确信这张PNG是网络传输中“完好无损”的。这正是本项目区别于普通图片加载的核心价值它不追求快而追求“可证明的正确”。3. 核心细节解析HTTP响应报文结构与PNG规范的硬核对照3.1 HTTP响应报文的四段式结构从状态行到PNG数据一个标准的HTTP/1.1响应报文严格遵循四段式结构中间由\r\n回车换行分隔HTTP/1.1 200 OK\r\n Content-Type: image/png\r\n Content-Length: 12480\r\n Date: Mon, 15 Apr 2024 08:23:15 GMT\r\n \r\n 12480字节的PNG二进制数据第一段状态行Status Line格式为HTTP-Version SP Status-Code SP Reason-Phrase CRLF。例如HTTP/1.1 200 OK。其中SP是空格CRLF是\r\n。状态码200表示成功Reason-Phrase原因短语如OK仅为人类可读程序应以状态码为准。注意HTTP/2不再使用此文本格式但本项目聚焦HTTP/1.1这是绝大多数PNG资源的实际传输协议。第二段响应头Response Headers由若干Field-Name: Field-Value CRLF组成如Content-Type: image/png。关键头字段包括Content-Type必须为image/png否则浏览器可能拒绝解析或触发MIME类型嗅探Sniffing带来安全风险Content-Length声明响应体字节数是判断数据是否完整的黄金标准。若服务器使用Transfer-Encoding: chunked则此头不存在需按分块规则解析Content-Encoding如gzip表示响应体已被压缩需先解压再解析PNGConnectionclose表示本次连接结束后关闭keep-alive则复用连接。第三段空行Empty Line单独一个\r\n是响应头与响应体的绝对分界线。这是解析中最易出错的点很多初学者用indexOf(\n)查找但HTTP规范要求\r\n若服务器仅发\nUnix风格或客户端误处理\r会导致空行定位偏移后续所有解析错位。第四段响应体Message Body纯二进制数据长度由Content-Length或chunked编码规则决定。对于PNG这就是完整的文件字节流从89 50 4E 47...开始到文件末尾49 45 4E 44 AE 42 60 82IEND块结束。提示在XMLHttpRequest中xhr.status和xhr.statusText已帮你提取了状态行xhr.getAllResponseHeaders()返回所有头字段字符串含\r\n而xhr.response当responseTypearraybuffer时即为响应体。但空行位置仍需手动定位因为getAllResponseHeaders()不包含空行本身且response不包含头信息。3.2 PNG文件结构从签名到IEND的块链式组织PNGPortable Network Graphics采用严格的块Chunk结构每个块由四部分组成字段长度说明Length4字节块数据Data字段的字节数大端序Big-EndianChunk Type4字节块类型如IHDR、IDAT、IEND区分大小写Chunk DataLength字节块的实际数据如IHDR包含宽高、颜色类型等CRC4字节基于Chunk Type Chunk Data计算的循环冗余校验码大端序整个PNG文件必须以以下顺序包含关键块PNG签名8字节89 50 4E 47 0D 0A 1A 0A用于快速识别文件类型IHDR块13字节数据 12字节头尾必须为第一个块定义图像基本信息一个或多个IDAT块存储经过zlib压缩的像素数据是图像内容主体IEND块0字节数据 12字节头尾标志PNG文件结束。IHDR块的数据结构13字节详解偏移长度字段说明04字节Width图像宽度像素大端序44字节Height图像高度像素大端序81字节Bit Depth位深度如8256色、1665536色91字节Color Type颜色类型0灰度、2真彩色、3索引色、4灰度Alpha、6真彩色Alpha101字节Compression Method压缩方法目前仅支持0zlib111字节Filter Method滤波方法目前仅支持0无滤波121字节Interlace Method互交错方法0非交错、1Adam7交错注意所有多字节整数Width、Height、Length、CRC均采用大端序Network Byte Order即高位字节在前。JavaScript中DataView的getUint32(offset, false)第二个参数false即表示大端序这是解析正确性的前提。3.3 实操关键如何从ArrayBuffer中精准定位空行与IHDR假设xhr.response是一个ArrayBuffer总长度为totalLen。我们需要从中分离出头信息含状态行和响应头和响应体PNG数据。步骤如下将ArrayBuffer转为Uint8Array便于字节操作const uint8Array new Uint8Array(xhr.response);查找空行\r\n\r\n的位置由于HTTP规范要求\r\n我们搜索连续的四个字节0x0D, 0x0A, 0x0D, 0x0A。注意不能简单用String.fromCharCode转字符串再indexOf因为PNG体中可能包含0x0D或0x0A导致误匹配。必须在Uint8Array上进行二进制搜索function findDoubleCRLF(arr) { for (let i 0; i arr.length - 3; i) { if (arr[i] 0x0D arr[i1] 0x0A arr[i2] 0x0D arr[i3] 0x0A) { return i 2; // 返回空行后第一个字节的索引即响应体起始位置 } } return -1; } const bodyStartIndex findDoubleCRLF(uint8Array); if (bodyStartIndex -1) throw new Error(未找到空行 \\r\\n\\r\\n);提取响应头字符串用于解析Content-Length等头信息是从uint8Array[0]到bodyStartIndex - 2因为\r\n\r\n占4字节bodyStartIndex指向第二个\r\n的起始所以头结束于bodyStartIndex - 2const headerBytes uint8Array.slice(0, bodyStartIndex - 2); const headerStr new TextDecoder().decode(headerBytes);解析Content-Length从headerStr中提取Content-Length值。注意头字段名不区分大小写但值可能有空格const contentLengthMatch headerStr.match(/^Content-Length:\s*(\d)/mi); const expectedBodyLen contentLengthMatch ? parseInt(contentLengthMatch[1], 10) : 0; const actualBodyLen uint8Array.length - bodyStartIndex; if (actualBodyLen ! expectedBodyLen) { console.warn(警告Content-Length(${expectedBodyLen})与实际体长(${actualBodyLen})不符); }定位IHDR块PNG签名固定为8字节因此IHDR块应从bodyStartIndex 8开始。读取该位置的4字节判断是否为IHDRASCII码0x49, 0x48, 0x44, 0x52const pngStart bodyStartIndex; if (uint8Array[pngStart] ! 0x89 || uint8Array[pngStart1] ! 0x50 || uint8Array[pngStart2] ! 0x4E || uint8Array[pngStart3] ! 0x47) { throw new Error(PNG签名不匹配); } const ihdrStart pngStart 8; // 跳过8字节签名 if (uint8Array[ihdrStart] ! 0x49 || uint8Array[ihdrStart1] ! 0x48 || uint8Array[ihdrStart2] ! 0x44 || uint8Array[ihdrStart3] ! 0x52) { throw new Error(IHDR块未在预期位置); }实操心得我曾在一个CDN环境下遇到Content-Length头被意外删除的情况导致expectedBodyLen0但actualBodyLen正常。此时必须依赖PNG文件自身的IEND块来确定结尾——搜索49 45 4E 44 AE 42 60 82IEND签名其位置即为PNG数据终点。这要求你实现一个从pngStart开始的全文件扫描虽然慢但保证了鲁棒性。4. 实操过程从发起请求到Canvas渲染的完整代码实现4.1 步骤一发起HTTP请求并获取原始响应function fetchRawPNG(url) { return new Promise((resolve, reject) { const xhr new XMLHttpRequest(); xhr.open(GET, url, true); xhr.responseType arraybuffer; // 关键获取原始二进制 // 设置超时避免无限等待 xhr.timeout 10000; xhr.onload function() { if (xhr.status 200 xhr.status 300) { resolve({ status: xhr.status, statusText: xhr.statusText, headers: xhr.getAllResponseHeaders(), response: xhr.response, url: url }); } else { reject(new Error(HTTP ${xhr.status} ${xhr.statusText})); } }; xhr.onerror function() { reject(new Error(网络请求失败)); }; xhr.ontimeout function() { reject(new Error(请求超时)); }; xhr.send(); }); }这段代码是整个流程的基石。responseType arraybuffer确保我们拿到的是未经任何编码转换的原始字节流这是后续所有解析的前提。注意xhr.getAllResponseHeaders()返回的是字符串包含所有头字段但不包含状态行HTTP/1.1 200 OK状态行需通过xhr.status和xhr.statusText获取。4.2 步骤二解析HTTP响应报文结构function parseHTTPResponse(rawData) { const uint8Array new Uint8Array(rawData.response); const totalLen uint8Array.length; // 1. 查找空行 \r\n\r\n let bodyStartIndex -1; for (let i 0; i totalLen - 3; i) { if (uint8Array[i] 0x0D uint8Array[i1] 0x0A uint8Array[i2] 0x0D uint8Array[i3] 0x0A) { bodyStartIndex i 2; // 指向空行后第一个字节 break; } } if (bodyStartIndex -1) { throw new Error(HTTP响应中未找到空行 \\r\\n\\r\\n); } // 2. 提取并解析响应头 const headerBytes uint8Array.slice(0, bodyStartIndex - 2); const headerStr new TextDecoder().decode(headerBytes); // 解析关键头字段 const headers {}; const headerLines headerStr.split(/\r\n|\n/); for (const line of headerLines) { if (!line.trim()) continue; const [key, ...valueParts] line.split(:); if (key valueParts.length 0) { const value valueParts.join(:).trim(); headers[key.trim().toLowerCase()] value; } } // 3. 提取响应体PNG数据 const pngData uint8Array.slice(bodyStartIndex); return { status: rawData.status, statusText: rawData.statusText, headers: headers, pngData: pngData, rawHeaderStr: headerStr, bodyStartIndex: bodyStartIndex }; }此函数完成了HTTP报文的“外科手术式”拆解。它将原始ArrayBuffer精确切分为头信息和PNG体并将头字段解析为小写键名的对象如headers[content-length]方便后续访问。rawHeaderStr保留原始头字符串供调试时查看。4.3 步骤三深度解析PNG结构并校验function parsePNG(pngData) { const view new DataView(pngData.buffer); const len pngData.length; // 1. 魔数校验 if (len 8) throw new Error(PNG数据过短不足8字节); if (pngData[0] ! 0x89 || pngData[1] ! 0x50 || pngData[2] ! 0x4E || pngData[3] ! 0x47 || pngData[4] ! 0x0D || pngData[5] ! 0x0A || pngData[6] ! 0x1A || pngData[7] ! 0x0A) { throw new Error(PNG魔数校验失败); } let offset 8; // 跳过8字节签名 // 2. 查找并解析IHDR块 let ihdr null; while (offset len - 12) { // 至少剩余12字节LengthTypeCRC // 读取Length4字节大端 const length view.getUint32(offset, false); // 读取Chunk Type4字节 const typeBytes [ pngData[offset 4], pngData[offset 5], pngData[offset 6], pngData[offset 7] ]; const typeStr String.fromCharCode(...typeBytes); // 计算该块总长度Length 4(Type) 4(CRC) Length 8 const chunkTotalLen length 8; if (offset chunkTotalLen len) { throw new Error(IHDR块数据超出PNG文件长度offset${offset}, length${length}); } if (typeStr IHDR) { // IHDR数据从offset8开始共13字节 const dataStart offset 8; if (dataStart 13 len) throw new Error(IHDR数据不完整); ihdr { width: view.getUint32(dataStart, false), height: view.getUint32(dataStart 4, false), bitDepth: pngData[dataStart 8], colorType: pngData[dataStart 9], compression: pngData[dataStart 10], filter: pngData[dataStart 11], interlace: pngData[dataStart 12] }; // CRC校验对TypeData计算CRC32 const crcData new Uint8Array(17); // 4(Type) 13(Data) crcData.set(typeBytes, 0); crcData.set(pngData.slice(dataStart, dataStart 13), 4); const expectedCRC view.getUint32(offset 8 13, false); const actualCRC crc32(crcData); if (actualCRC ! expectedCRC) { throw new Error(IHDR块CRC校验失败期望${expectedCRC.toString(16)}实际${actualCRC.toString(16)}); } break; } offset chunkTotalLen; } if (!ihdr) throw new Error(未在PNG中找到IHDR块); // 3. 收集所有IDAT块数据 let idatData new Uint8Array(0); offset 8; // 重置偏移重新扫描 while (offset len - 12) { const length view.getUint32(offset, false); const typeBytes [ pngData[offset 4], pngData[offset 5], pngData[offset 6], pngData[offset 7] ]; const typeStr String.fromCharCode(...typeBytes); const chunkTotalLen length 8; if (typeStr IDAT) { const dataStart offset 8; const newData pngData.slice(dataStart, dataStart length); const newIdatData new Uint8Array(idatData.length newData.length); newIdatData.set(idatData, 0); newIdatData.set(newData, idatData.length); idatData newIdatData; // IDAT CRC校验 const crcData new Uint8Array(4 length); crcData.set(typeBytes, 0); crcData.set(newData, 4); const expectedCRC view.getUint32(offset 8 length, false); const actualCRC crc32(crcData); if (actualCRC ! expectedCRC) { throw new Error(IDAT块CRC校验失败期望${expectedCRC.toString(16)}实际${actualCRC.toString(16)}); } } else if (typeStr IEND) { break; // 遇到IEND停止扫描 } offset chunkTotalLen; } if (idatData.length 0) throw new Error(PNG中未找到IDAT块); return { signature: pngData.slice(0, 8), ihdr: ihdr, idatData: idatData, width: ihdr.width, height: ihdr.height, colorType: ihdr.colorType }; } // 简化版CRC32实现仅用于演示生产环境建议用成熟库 function crc32(data) { const table [ 0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, // ... 完整表省略实际需64项 ]; let crc 0xFFFFFFFF; for (let i 0; i data.length; i) { const byte data[i]; const idx (crc ^ byte) 0xFF; crc (crc 8) ^ table[idx]; } return crc ^ 0xFFFFFFFF; }此函数是整个项目的技术核心。它不仅解析IHDR获取宽高更严格执行了PNG规范的三大校验魔数、IHDR CRC、IDAT CRC。crc32函数虽为简化版但足以验证校验逻辑。注意view.getUint32(offset, false)的false参数这是大端序解析的关键若误用true小端序宽高值将完全错误。4.4 步骤四将解析结果渲染到Canvasfunction renderPNGToCanvas(pngInfo, canvas) { const ctx canvas.getContext(2d); // 创建ImageBitmap现代方式支持直接传入Uint8Array // 若浏览器不支持回退到Blob URL if (typeof createImageBitmap function) { const blob new Blob([pngInfo.idatData], {type: image/png}); return createImageBitmap(blob).then(bitmap { canvas.width pngInfo.width; canvas.height pngInfo.height; ctx.drawImage(bitmap, 0, 0); return bitmap; }); } else { // 回退方案Blob URL const blob new Blob([pngInfo.idatData], {type: image/png}); const url URL.createObjectURL(blob); return new Promise((resolve, reject) { const img new Image(); img.onload () { canvas.width pngInfo.width; canvas.height pngInfo.height; ctx.drawImage(img, 0, 0); URL.revokeObjectURL(url); // 释放内存 resolve(img); }; img.onerror () reject(new Error(Image加载失败)); img.src url; }); } } // 使用示例 async function main() { try { const rawData await fetchRawPNG(https://example.com/test.png); console.log(✅ HTTP响应获取成功状态码, rawData.status); const httpParsed parseHTTPResponse(rawData); console.log(✅ HTTP报文解析完成响应头, httpParsed.headers); const pngInfo parsePNG(httpParsed.pngData); console.log(✅ PNG结构解析完成图像尺寸, pngInfo.width, x, pngInfo.height); const canvas document.getElementById(myCanvas); await renderPNGToCanvas(pngInfo, canvas); console.log(✅ PNG已渲染到Canvas); } catch (error) { console.error(❌ 执行失败, error.message); } } main();此段代码展示了从解析到渲染的闭环。renderPNGToCanvas优先使用createImageBitmap这是现代浏览器推荐的方式能绕过Blob URL的内存泄漏风险若不支持则优雅降级。URL.revokeObjectURL的调用是关键避免长期持有Blob引用导致内存占用飙升。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 问题速查表高频故障点与定位方法问题现象可能原因定位方法解决方案未找到空行 \r\n\r\n服务器返回HTTP/0.9无头响应被代理截断CDN注入HTML错误页检查xhr.response前100字节的十六进制值用Wireshark抓包对比确认URL是否指向真实PNG资源检查CDN配置对HTTP/0.9需特殊处理无头直接解析体PNG魔数校验失败URL返回了HTML如404页面、JSON错误、重定向响应服务器启用了Gzip但未声明Content-Encoding将xhr.response转为字符串console.log(new TextDecoder().decode(uint8Array.slice(0, 100)))检查Content-Type头是否为image/png确认服务器未启用未声明的压缩用curl -I验证响应头IHDR块CRC校验失败网络传输中字节损坏服务器生成PNG时CRC计算错误CDN缓存了损坏版本用pngcheck -v yourfile.png本地验证对比原始文件与HTTP响应体的MD5联系服务器管理员更换CDN节点添加ETag校验Canvas渲染黑屏或异常PNG颜色类型不支持如colorType4灰度AlphaCanvas需转换宽高为0或过大超出Canvas限制检查pngInfo.colorType打印canvas.width/height对colorType4需用ctx.getImageData读取像素并手动合成Alpha设置Canvas最大尺寸限制IDAT数据为空服务器返回了空PNG文件IEND块位置错误导致扫描提前终止搜索49 45 4E 44IEND在pngData中的位置检查offset循环是否越界修正IEND搜索逻辑添加if (typeStr IEND) break;在IDAT收集循环中5.2 实操避坑指南来自真实项目的血泪教训坑一TextDecoder的编码陷阱初版代码用new TextDecoder(utf-8)解码响应头但在某些服务器尤其Windows IIS返回的头中包含非UTF-8字符如ISO-8859-1编码的Content-Disposition导致TextDecoder抛出异常。解决方案是改用new TextDecoder(latin1)因为HTTP头字段值在ASCII范围内latin1能无损映射所有0-255字节且不会抛错。TextDecoder的latin1模式是Web API标准兼容性极佳。坑二ArrayBuffer的共享内存风险在解析过程中我曾将pngData.slice()的结果直接传给createImageBitmap结果在Chrome中出现随机渲染错误。排查发现slice()返回的是原ArrayBuffer的视图view当原ArrayBuffer被GC回收时视图可能失效。正确做法是new Uint8Array(pngData).buffer创建新副本或直接用pngData.buffer因pngData已是Uint8Array其buffer属性即底层内存。坑三跨域限制下的“伪成功”当请求跨域PNG资源时若服务器未设置Access-Control-Allow-OriginXMLHttpRequest的xhr.response可能为空但xhr.status仍为0xhr.statusText为空字符串。此时parseHTTPResponse会因uint8Array.length 0而崩溃。必须在xhr.onload中增加if (xhr.response instanceof ArrayBuffer xhr.response.byteLength 0)的判断并给出明确错误提示“跨域请求被阻止请检查CORS头”。坑四Content-Length与Transfer-Encoding: chunked的冲突HTTP规范禁止同时发送Content-Length和Transfer-Encoding: chunked但某些老旧代理会违规操作。当headers[transfer-encoding] chunked时