我很难理解这个标题是如何工作的。
简单地说，我的问题是
如果我要求某个资源的帖子，那就让我们来吧 比如在第一种情况下，响应是一些json字符串，在第二种情况下，响应是一个.jar文件。
1.客户端是否包括accept-header：gzip，在发送HTTP请求的两种情况下都会收缩，知道第一个会导致json字符串吗？
2.如果响应已经压缩了，现在压缩已经压缩的数据的响应不会产生问题吗？
3.如果我包含accept-encoding，那么会发生什么：在第一种情况下接收json字符串的gzip。所以我收到一个压缩数据作为我的回复（我甚至不确定是否获得压缩数据或某些编码数据作为响应。我认为压缩数据意味着压缩像.jar / .zip这样的东西和编码数据意味着原始数据的编码数据，哪一个正在进行压缩或编码？）
4.假设服务器发送带有Contentype标头的响应为＆＃34; application / octet-stream＆＃34;。现在必须使用accept-header：gzip，deflate
答案 0 :(得分：1)
是的，为什么不呢？如果JSON有效负载很大，压缩它会很有意义。
这只是开销。
您可能接收 gzipped 数据 - 而不是ZIP文件。您可能需要阅读RFC 7230和RFC 7231以获取详细信息。
有效载荷的互联网媒体类型完全独立于内容编码。
答案 1 :(得分：1)
客户端可以使用Accept-Encoding HTTP请求标头告诉服务器它可以接受压缩响应。
服务器可以使用请求标头来决定是否应该发送压缩响应。它可以忽略标头并始终发送非压缩响应（可能效率较低）。它可以忽略标头并始终发送压缩响应（冒着给客户端提供无法解码的响应的风险）。
客户端是否应包含accept-header：gzip，两种情况下都是deflate
我想不出任何理由不告诉服务器客户端可以处理压缩响应（假设事实是真的）。
如果响应已经压缩了，现在压缩已经压缩的数据的响应会产生问题
如果节省很少或没有字节数，可能会浪费处理器能力。
这并不是客户说它无法处理压缩响应的原因。这是决定在服务器上做出的。
如果我在第一种情况下包含accept-encoding：gzip，会收到json字符串会发生什么。
然后客户端告诉服务器压缩响应是可接受的。
所以我收到一个压缩数据作为我的回复
服务器可能发送压缩响应。它可能会忽略标题。
我甚至不确定是否将压缩数据或某些编码数据作为响应
这里没有“或”。
使用压缩算法对数据进行编码。
让我们说服务器将Contentype标头的响应发送为“application / octet-stream”
这只意味着服务器不知道它发送的数据类型。它不是说“这是JSON”或“这是一个jar文件”，而是说“我不知道这是什么，它对我来说只是一个字节流”。
现在必须使用accept-header：gzip，deflate
它没有任何区别。
服务器可以压缩数据。它可以发送未压缩的数据。它可以使用Accept-Encoding请求标头来决定两者中的哪一个。