Http Header 接受编码

Question

我很难理解这个标题是如何工作的。

简单来说我的问题是

如果我请求发布到某个资源，那么让我们 说在第一种情况下响应是一些 json 字符串，在第二种情况下响应是一个 .jar 文件。

1.客户端是否应该在发送HTTP请求时包含accept-header:gzip,deflate在这两种情况下，知道第一个结果是json字符串？

2.如果响应已经被压缩了怎么办，现在将响应压缩到已经压缩的数据上不会产生问题？

3. 如果我在收到 json 字符串的第一种情况下包含 accept-encoding:gzip 会发生什么。所以我收到一个压缩数据作为我的响应（我什至不确定是否得到压缩数据或一些编码数据作为响应。我认为压缩数据意味着像 .jar/.zip 这样的压缩数据，编码数据意味着原始数据的编码数据，哪一个发生了压缩或编码）？

4.假设服务器将 Contentype 标头作为“application/octet-stream”的响应发送。现在是不是必须使用accept-header:gzip,deflate

Answer 1

客户端可以使用Accept-Encoding HTTP 请求标头告诉服务器它可以接受压缩响应。

服务器可以使用请求头来决定它是否应该发送压缩响应。它可以忽略标头并始终发送非压缩响应（可能效率较低）。它可以忽略标头并始终发送压缩响应（冒着给客户端无法解码的响应的风险）。

客户端是否应该在这两种情况下都包含accept-header:gzip,deflate

我想不出任何理由不告诉服务器客户端可以处理压缩响应（假设事实是真的）。​​

如果响应已经压缩了怎么办，现在将响应压缩到已经压缩的数据上不会产生问题

这可能是对处理器能力的浪费，很少或根本没有节省字节数。

这不是客户说它无法处理压缩响应的理由。这是在服务器上做出的决定。

如果我在收到 json 字符串的第一种情况下包含 accept-encoding:gzip 会发生什么。

然后客户端告诉服务器压缩响应是可以接受的。

所以我收到一个压缩数据作为我的回复

服务器可能发送一个压缩响应。它可能会忽略标题。

我什至不确定是否获取压缩数据或一些编码数据作为响应

这里没有“或”。

使用压缩算法对数据进行编码。

假设服务器将 Contentype 标头作为“application/octet-stream”发送的响应

这只是意味着服务器不知道它正在发送什么类型的数据。不是说“这是 JSON”或“这是一个 jar 文件”，而是说“我不知道这是什么，对我来说它只是一个字节流”。

现在必须使用accept-header:gzip,deflate

这并没有什么不同。

服务器可以压缩数据。它可以发送未压缩的数据。它可以使用Accept-Encoding请求头来决定两者中的哪一个。

Answer 2

1. 是的，为什么不呢？如果 JSON 负载很大，压缩它会很有意义。

2. 只是开销而已。

3. 您可能收到 gzipped 数据 - 不是 ZIP 文件。您可能需要阅读 RFC 7230 和 RFC 7231 了解详细信息。

4. 负载的互联网媒体类型完全独立于内容编码。