似乎Nginx不能很好地支持chunked请求.但我正在努力获得更明确(当前)的答案.我有一个客户端从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很好吗？我还忘记了其他解决方法吗？
解决方法:
我收集了这个问题所有部分的答案.
Base Nginx不支持分块请求(正如Alexander确认的那样！). Nginx可以使用NginXHttpCunkinModule来支持分块请求(正如我的问题所提到的).更好：这个模块在18个月前从测试状态升级到生产质量.最佳：我最近在meetup与CloudFoundry工程团队的一些成员进行了交谈;他们确认计划将此模块添加到他们的Nginx版本中.问题解决了. (嗯,从长远来看,它已经完全解决了.但我们没有确切的日期来确定何时发生这种情况.)
回答我向亚历山大提出的问题：不可能发送带有分块消息的“Content-Length”.这真的是分块消息的重点：你在拥有完整内容之前就开始发送它们,所以你不可能知道它的长度.所以他避免分块请求的想法是正确的.但更实际的是,我会说,“使用HTTP / 1.0而不是HTTP / 1.1.”这具有不发送分块消息的效果.我们能够临时修补我们的客户以测试这个想法.有效.但我们不打算推出一个公共补丁.让每个人都使用一个有十年历史的协议(以及一个10年不受支持的客户端库！)来解决这一问题的问题似乎适得其反.
相反,我会在需要时使用被黑客入侵的客户端,如果其他人发现需要,我会发送电子邮件,我们将等待CloudFoundry更新到HttpChunkin和HTTP / 1.1.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
