Mozilla 开发者网络上的这个页面，质量通常不会太差，它指出：
* 匹配标题中尚未列出的任何内容编码。如果标头不存在，这是默认值。这并不意味着支持任何算法；只是没有表达偏好。
现在我发现 Elasticsearch 继续前进，当我告诉它时发送 gzip，Accept-Encoding: *但当我省略标题时发送纯数据。
在我看来，这意味着这两个句子都是错误的：
如果标头不存在，这是默认值。
Accept-Encoding: *在这种情况下，无论是否给出标题，行为都应该是相同的。
这并不意味着支持任何算法；只是没有表达偏好。
对 Elasticsearch 来说，这似乎意味着：发送 gzip 就可以了。
我是否误解了它们在 MDN 中的含义？该页面上的信息是否完全错误（毕竟它有编辑按钮）？或者 Elasticsearch 是否在做一些不应该做的事情？
这里的错误行为是什么？
编辑：确切的预期行为在RFC 2616（过时）第 14.3 节https://www.rfc-editor.org/rfc/rfc2616#section-14.3 RFC 7231 https://www.rfc-editor.org/中定义rfc/rfc7231#section-5.3.4
我的理解是，如果您（HTTP 客户端）告诉 Elasticsearch 您可以接受任何内容编码，那么服务器可以自由选择它喜欢的任何编码来发送其数据（无论是纯文本还是 gzip）。然后，请参阅Content-Encoding标题以能够正确处理数据。
精确地看这两个句子：
如果标头不存在，这是默认值。
如果Content-Encoding标头不存在，则它等效于声明Content-Encoding = *。这意味着服务器可以使用它希望的任何内容编码。这并不意味着服务器必须始终使用相同的编码方案：这意味着服务器可以自由选择它想要的一种。
这并不意味着支持任何算法；只是没有表达偏好。
这句话适用于客户端（而不是服务器）。使用*时，客户端只是对服务器说“哦，无论你使用什么编码，我都可以。随意使用任何你想要的。”
在这两种情况下（没有Accept-Encoding标头或Accept-Encoding = *），纯文本、gzip 或任何其他编码方案都是合法的。至于 Elasticsearch 的实现，我的猜测如下：
Accept-Encoding标头，我可以假设客户端甚至不知道内容编码。使用纯文本更安全。Accept-Encoding标头，这意味着客户端知道内容编码并且它真的愿意接受任何东西。嗯，gzip 是一个节省带宽的好选择，并且得到了很好的支持。请注意，我在很大程度上是在解释：只有原始 Elasticsearch 开发人员的答案才是准确的。
如果您支持一组有限的内容编码，则不应使用*. 您应该更好地明确提供您支持的编码。