HTTP接受 "level"吗？

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

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

谢谢。

最佳答案

...几年后

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



摘自the RFC:



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

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

概括

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

RFC

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

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



来源: 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的示例:



来源: 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相互补充



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

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



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

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

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

含义冲突



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

我发现的其他东西

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

完全不提及level的

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

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

结论

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

关于HTTP接受 "level"吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/13890996/