HTTP请求压缩
一般用例
想象一个客户端正在上传大量JSON。Content-Type应该保留，application/json因为它描述了实际数据。Accept-Encoding和Transfer-Encoding似乎是在告诉服务器应如何格式化响应。看来，响应为此目的明确使用了Content-Encoding头，但这不是有效的请求头。
我有什么想念的吗？有没有人找到一个优雅的解决方案？
具体用例
我的用例是，我有一个移动应用程序，该应用程序生成大量的JSON（在某些情况下，但是程度较小的情况下，还会生成一些二进制数据），并且压缩请求可以节省大量的带宽。我使用Tomcat作为我的Servlet容器。我将Spring用于其MVC批注，主要是为了将JEE的某些内容抽象为一个更加简洁，基于批注的接口。我还使用Jackson进行自动（反序列化）。
我也使用nginx，但是我不确定那是否是我想要进行减压的地方。Nginx节点仅平衡请求，然后通过数据中心分发这些请求。保持压缩，直到它真正到达要处理的节点，这同样好。
提前致谢，
回答：
似乎[Content-Encoding]不是有效的请求标头。
这实际上不是很正确。根据RFC 2616，sec 14.11，Content-Encoding是一个实体标头，这意味着它可以应用于http响应和请求的实体。通过多部分MIME消息的功能，甚至可以压缩请求（或响应）的选定部分。
但是，Web服务器对压缩的请求正文的支持非常有限。Apache通过mod_deflate模块在一定程度上支持它。我还不清楚nginx是否可以处理压缩请求。
以上是 HTTP请求压缩 的全部内容， 来源链接： utcz.com/qa/431800.html
