HTTP接受 "level"吗？

Question

我一直在阅读HTTP/1.1 headers，并在14.1节(接受)的一些示例 header 中使用了accept-extension，level=1等(我相信是这样)。

我遇到的问题是他们使用这些level=2东西，好像他们在做什么很明显。该文档是否仅能说明问题？还是我遗漏了一些东西？

谢谢。

Answer 1

...几年后

用户TomWardrop指出了这一点(从评论到此答案):

It use to be part of the text/html media type specification to indicate what version of HTML you wanted, but is wasn't used much (if at all), so it was dropped. Refer to ietf.org/rfc/rfc2854.txt.

摘自 the RFC:

Note that [HTML20] included an optional "level" parameter; in practice, this parameter was never used and has been removed from this specification. [HTML30] also suggested a "version" parameter; in practice, this parameter also was never used and has been removed from this specification.

到目前为止，这似乎是最好的答案。

我将以下原始答案留给后代引用。

概括

通过RFC-2616(征求意见)在 IETF和 W3C以及Internet上其他网站上的浏览，似乎没有很好地记录或解释 level扩展名。似乎也没有任何人在 header 中使用它，这表明它可能可以忽略。

RFC

在RFC中，在一些示例中可以看到 level参数，但从未提及或明确表达了它所起的作用。

在关于优先级的示例中使用了 level:

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

    Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

    1) text/html;level=1
    2) text/html
    3) text/*
    4) */*

来源: IEFT RFC-2616 p.100和 W3C RFC2616 section "14.1 Accept"

看到两个示例中的类型排序方式之间的差异，看起来 text/html;level=1的优先级比 text/html的优先级高，这意味着 level扩展名必须为其赋予该优先级。根据降低的特异性，最后两个显然有进一步的顺序。

现在，这带来了品质因数 q。在RFC中对此进行了很好的解释。可以是 between 0 and 1 。值越大，类型的优先级越高。 RFC有一个同时使用 q和 level的示例:

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,

    Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
            text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

    text/html;level=1         = 1
    text/html                 = 0.7
    text/plain                = 0.3

    image/jpeg                = 0.5
    text/html;level=2         = 0.4
    text/html;level=3         = 0.7

来源: IEFT RFC-2616 p.100和 W3C RFC2616 section "14.1 Accept"

由此看来， level的值用于降低优先级(1具有最高优先级，2具有第二高优先级，等等)。这是有道理的，但是当与 Accept: header 一起使用时，这根本没有任何意义:

首先，q参数在关联中(以下)从类型中神奇消失了。就像作者以为很明显为什么省略了它们，却忘了告诉我们为什么很明显了。

其次，Accept: header 中的类型与关联中显示的类型(如下所示)不是相同的类型。例如， header 中从未提到image/jpeg类型，并且关联中缺少text/*类型。

我无所适从地解释了这一切的含义。

Zend框架讨论

在 answer to a question asking about the level parameter上，有一些有趣的东西。
q和 level相互补充

[...] The q-factor is the one most looked at. However, you can also specify a "level", and these CAN also act like priorities, but operate in the order of decreasing precedence (i.e., level 1 is higher priority than level 2). The examples they have in the spec are contrived, and, tbh, confusing at best [...]

应该使用 q参数，并且可以使用 level参数。好的，但是它仍然不能完全弄清它的作用以及应该如何影响类型的优先级。

用于支持的类型/规范版本

Another documented use case for the "level" is to indicate the _version_ of the type. As an example, a "level 1" might indicate the first version of that spec available. In such cases, it wouldn't be a priority, but instead a _descriptor_ [...]

因此，一种指示支持哪种类型的类型的方法。现在，这实际上更有意义:

text/html;level=5;q=1
text/html;level=4.01;q=0.9
; Etc.

但是，我以某种方式怀疑 level是否应该用于此目的。如果是这样的话，它可能会被称为更具描述性的内容，例如 version，或者简称为 v(例如 q)。

含义冲突

Unfortunately, the "level" selector has conflicting meanings, so I'm not 100% sure we should support it by default; "q", on the other hand, is well documented.

是的。含义冲突且记录不充分。 level属性几乎没有用。

我发现的其他东西

在Internet上其他地方寻找问题/答案时，我发现:

完全不提及 level的

A seriously old-school document。它实际上提到了另外两个，mxs和mxb。

Moz Dev page列出来自各种浏览器的常见Accept header 。无处使用level。实际上，我从未见过它在RFC之外使用。

结论

总之，我认为可以肯定地说 level是浪费时间。它的文献记录不充分，在实践中很少使用(如果真的使用过的话)，而且比它值得的还令人困惑。