似乎nginx不能很好地支持分块请求。但我正在努力获得更明确（当前）的答案。我有一个客户端从Java客户端向服务器发出SOAP请求，该客户端设置头Transfer-Encoding: chunked。当我直接连接到Tomcat上的应用程序时，一切正常。
但是当我把nginx放在它们之间时，事情就会破裂。
添加一些细节：我正在使用CloudFoundry。我正在使用Micro Cloud Foundry确认在没有nginx的情况下，事情按预期工作。但我的要求是使用cloudfoundry.com，所以我没有能力绕过那里的nginx。
This question and answer说这可能是我唯一的解决方法：http://wiki.nginx.org/NginxHttpChunkinModule。但是这种解决方法不可用，因为我无法在cloudfoundry.com上修改配置。
This question看起来也很相似，但它实际上涵盖了此要求的相反方向。它涵盖了分块响应而不是分块请求。
那么客户端的任何变化如何解决这个问题呢？是否可以将Transfer-Encoding: chunked和Content-Length: 123作为标题发送？这个领域对我来说是新的，但似乎像Apache HttpComponents这样的项目可以设置长度或分块但不是两者。分块的重点是您不需要知道请求开始时的长度。我可以告诉我的客户端使用HTTP / 1.0并在没有分块的情况下使用nginx很好吗？还有其他我忘记的解决方法吗？
答案 0 :(得分：4)
我收集了这个问题所有部分的答案。
Base nginx不支持分块请求（正如Alexander确认的那样！）。 Nginx可以使用NginXHttpCunkinModule支持分块请求（正如我的问题所提到的）。更好：这个模块在18个月前从测试状态升级到生产质量。最佳：我最近在meetup与一些CloudFoundry工程团队的成员进行了交谈。他们确认计划将此模块添加到他们的nginx版本中。问题解决了。 （嗯，从长远来看，它已经完全解决了。但我们没有确切的日期来确定何时发生这种情况。）
因此，短期解决方案也会很好。我找到了一个。
回答我向亚历山大提出的问题：无法使用分块信息发送“内容长度”。这真的是分块消息的重点：你在拥有完整内容之前就开始发送它们，所以你不可能知道它的长度。所以他避免分块请求的想法是正确的。但更实际的是，我会说，“使用HTTP / 1.0而不是HTTP / 1.1。”这具有不发送分块消息的效果。我们能够临时修补我们的客户以测试这个想法。有效。但我们不打算推出一个公共补丁。让每个人都使用一个有十年历史的协议（以及一个10年不受支持的客户端库！）来解决这种情况的问题似乎适得其反。
相反，我会在需要时使用被黑客入侵的客户端，如果其他人发现需要，我会发送电子邮件，我们将等待CloudFoundry更新到HttpChunkin和HTTP / 1.1。
答案 1 :(得分：2)
Nginx确实不支持分块请求。如果没有411 Content Length required标题，它会返回Content-Length。
由于您正在控制客户端代码，我想唯一的选择是避免使用分块请求并明确指定Content-Length。