HTTP请求压缩 [英] HTTP request compression
问题描述
一般用例
想象一下，上传大量JSON的客户端。 Content-Type应该保持 application / json ，因为它描述了实际的数据。接受编码和传输 - 编码似乎是告诉服务器它应该如何格式化响应。看起来， 响应明确地为此目的使用了Content-Encoding头，但它不是有效的请求头。
Imagine a client that is uploading large amounts of JSON. The Content-Type should remain application/json because that describes the actual data. Accept-Encoding and Transfer-Encoding seem to be for telling the server how it should format the response. It appears that responses use the Content-Encoding header explicitly for this purpose, but it is not a valid request header.
有没有我缺少的东西？有人发现了优雅的解决方案吗？
Is there something I am missing? Has anyone found an elegant solution?
特定用例
-case是，我有一个移动应用程序生成大量的JSON（在一些情况下，一些二进制数据但在较小程度上），压缩请求节省了大的带宽量。我使用Tomcat作为我的Servlet容器。我使用Spring的MVC注释主要只是将一些JEE东西抽象成一个更干净，基于注释的界面。我也使用Jackson来进行自动（de）序列化。
My use-case is that I have a mobile app that is generating large amounts of JSON (and some binary data in some cases but to a lesser extent) and compressing the requests saves a large amount of bandwidth. I am using Tomcat as my Servlet container. I am using Spring for it's MVC annotations primarily just to abstract away some of the JEE stuff into a much cleaner, annotation-based interface. I also use Jackson for auto (de)serialization.
我也使用nginx，但我不知道这是否需要解压缩。 nginx节点简单地平衡请求，然后通过数据中心分布。
I also use nginx, but I am not sure if thats where I want the decompression to take place. The nginx nodes simply balance the requests which are then distributed through the data center. It would be just as nice to keep it compressed until it actually got to the node that was going to process it.
提前感谢，
约翰
编辑：
我和@DaSourcerer之间的讨论真的有助于那些在写这篇文章时对事物状态好奇的人。
The discussion between myself and @DaSourcerer was really helpful for those that are curious about the state of things at the time of writing this.
我最终实现了自己的解决方案。注意，这指定分支ohmage-3.0，但它很快将被合并到主分支。您可能想查看是否已进行任何更新/修正。
I ended up implementing a solution of my own. Note that this specifies the branch "ohmage-3.0", but it will soon be merged into the master branch. You might want to check there to see if I have made any updates/fixes.
推荐答案
出现[Content-Encoding]不是有效的请求标头。
It appears [Content-Encoding] is not a valid request header.
这实际上不是真的。根据 RFC 2616，第14.11 条， Content-Encoding 是一个实体头，这意味着它可以应用于http响应和请求的实体。通过多部分MIME消息的权力，甚至可以压缩请求（或响应）的部分。
That is actually not quite true. As per RFC 2616, sec 14.11, Content-Encoding is an entity header which means it can be applied on the entities of both, http responses and requests. Through the powers of multipart MIME messages, even selected parts of a request (or response) can be compressed.
然而，webserver支持压缩请求体相当纤细。 Apache通过 mod_deflate code>模块。如果 nginx可以处理压缩的请求，我对此并不完全清楚。。
However, webserver support for compressed request bodies is rather slim. Apache supports it to a degree via the mod_deflate module. It's not entirely clear to me if nginx can handle compressed requests.
这篇关于HTTP请求压缩的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
