HTTP分块编码下内容长度获取及Nginx 400错误问题咨询

安全阿岳

2026-7-30

关于HTTP分块编码的两个问题解答

问题1：使用分块编码（`transfer-encoding: chunked`）时，HTTP服务器如何获取Content-Length？

分块编码的核心设计就是为了解决无法提前获知内容总长度的场景，HTTP规范明确规定：当请求/响应使用transfer-encoding: chunked时，Content-Length字段会被直接忽略。
服务器不需要依赖Content-Length处理数据：它会逐块读取内容，每块开头的十六进制数字标识当前块的长度，直到读取到标识为0的结束块。此时服务器可以通过累加所有块的长度，得到整个内容的总长度——但这个总长度只能在传输完成后获取，传输过程中无法提前获知。

问题2：同时设置Content-Length和Transfer-Encoding时Nginx返回400错误，以及分块编码下服务器如何获知实际文件大小？

Nginx返回400的原因

根据HTTP 1.1规范（RFC 7230），请求同时包含Content-Length和transfer-encoding: chunked属于不符合规范的请求头组合。虽然规范要求服务器忽略Content-Length，但Nginx为了严格规避潜在的解析错误或请求伪造风险，直接将这类请求判定为无效，返回400 Bad Request拒绝处理。

分块编码下服务器获知实际文件大小的方式

分两种场景：

若服务器是主动生成分块响应（比如读取本地文件后分块发送）：服务器可以直接通过文件系统API获取文件的实际大小，但不会在响应头中返回Content-Length，仍按分块格式传输数据。
若服务器是接收客户端的分块请求，或处理流式动态内容：服务器只能在所有分块数据接收/传输完成后，累加每个块的长度得到总大小，传输过程中无法提前知道完整的内容长度。