应用错误收集

Mozilla开发者网络上的

This page，质量通常不会太差，声明：

*匹配标头中尚未列出的任何内容编码。如果标头不存在，这是默认值。它并不意味着支持任何算法;只是没有表达偏好。

现在我发现当我告诉它Accept-Encoding: *时，Elasticsearch继续发送gzip，但是当我省略标题时发送简单数据。

在我看来，这意味着两个句子都是错误的：

如果标题不存在，这是默认值。

在这种情况下，行为应该是相同的，无论是Accept-Encoding: *还是根本没有标题。

这并不意味着支持任何算法;只是没有表达偏好。

对Elasticsearch来说，它似乎意味着：发送gzip很好。

我是否误解了他们在MDN中的含义？该页面上的信息是否完全错误（毕竟它有编辑按钮）？或者Elasticsearch正在做一些它本不该做的事情？

这里的错误行为是什么？

我的理解是，如果您（HTTP客户端）告诉Elasticsearch您可以接受任何内容编码，那么服务器可以自由选择它喜欢发送其数据的任何编码（无论是纯文本还是gzip）。然后，请参阅Content-Encoding标题以便能够正确处理数据。

准确地看两句话：

如果标题不存在，这是默认值。

如果Content-Encoding标头不存在，那么它等同于声明Content-Encoding = *。这意味着服务器可以使用它希望的任何内容编码。这并不意味着服务器必须始终使用相同的编码方案：这意味着服务器可以自由选择所需的编码方案。

这并不意味着支持任何算法;只是没有表达偏好。

这句话适用于客户（不是服务器）。当使用*时，客户端只是对服务器说“哦，无论你使用什么编码，我都没关系。随意使用你想要的任何编码。”

在这两种情况下（无Accept-Encoding标头或Accept-Encoding = *），纯文本，gzip或任何其他编码方案都是合法的。至于Elasticsearch实现，我的猜测如下：

作为服务器，如果我没有收到Accept-Encoding标题，我可以假设客户端甚至不知道内容编码。使用纯文本更安全。
作为服务器，如果我收到Accept-Encoding标头，则表示客户端知道内容编码，并且它真的愿意接受任何内容。嗯，gzip是一个很好的备用带宽选择，并得到很好的支持。

请注意，我在很大程度上解释：只有原始Elasticsearch开发人员的答案才是准确的。

如果您支持一组有限的内容编码，则不应使用*。您应该更明确地提供您支持的编码。