HTTP 1.1 - 传输的客户端请求不能被“分块”吗？

Posted 2023-02-24

【中文标题】HTTP 1.1 - 传输的客户端请求不能被“分块”吗？

【英文标题】：HTTP 1.1 - Can a client request that transfers not be "chunked"?

【发布时间】：2014-07-09 12:37:21

【问题描述】：

HTTP 1.1 客户端是否可以设置一个标头值来指示对请求的响应不应被分块？或者是防止这种情况的唯一方法是发送 HTTP 1.0 请求？我试过用谷歌搜索，但我能找到的只是在 HTTP 1.1 服务器上禁用分块传输的方法，所以我猜这在客户端上是不可能的，但我想我还是会问。

【参考方案1】：

在 HTTP（从 HTTP/1.1 开始）中，接收者必须支持分块编码。见http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-26.html#rfc.section.4.1.p.4。

【讨论】：

看来你是对的。尽管在阅读后我确实注意到这是标准的草案。如果其他人有兴趣，这里是最终标准ietf.org/rfc/rfc2616.txt 请参阅第 3.6.1 节的末尾

RFC 2616 是旧版本。该草案是当前规范，不久将作为 RFC 发布。

看起来你又是对的......如果它被批准了。您介意编辑您的答案，使其显示“在 HTTP 1.1 中，收件人...”。分块编码不是 HTTP 1.0 和更早版本的一部分。我试过了，但无论出于何种原因，我的编辑似乎都被还原了。

嗯...它之前没有显示为已批准，事实上，当我发表之前的评论时，它根本没有说它正在等待同行评审。现在确实出现了一个编辑，但它不是我的。无论如何，再次感谢您的帮助。

当我说“它被批准”时，我指的是规范。见：datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging

【参考方案2】：

使用 HTTP 1.1 以字节为单位而不是在响应中分块获取 Content-Length， 您必须根据您在响应中期望的文件设置 Content-Length 标头及其大小（long 或 int）。 long 会很好，因此它可以处理小文件和大文件。 响应将是 HttpServletResponse。 response.addHeader(Content-Length, Long.toString()); 谢谢，

【讨论】：

从服务器的角度来看这可能是正确的（虽然有点 Java 特定）但问题是关于从客户端请求这个。