http - HTTP 接受“级别”？

Question

我一直在阅读HTTP/1.1 标头和第 14.1 节（接受）中的一些示例标头，它们使用accept-extensions （我相信它们就是这样）称为level=1,level=2等。

我遇到的问题是他们使用这些level=X东西就好像他们所做的事情应该是显而易见的。文件只是无法解释它还是我遗漏了什么？

谢谢。

Answer 1

...几年后

用户 TomWardrop 指出（从评论到这个答案）：

它曾经是 text/html 媒体类型规范的一部分，用于指示您想要的 HTML 版本，但使用得不多（如果有的话），所以它被删除了。请参阅ietf.org/rfc/rfc2854.txt。

来自RFC 的摘录：

请注意，[HTML20] 包含一个可选的“级别”参数；实际上，该参数从未使用过，并且已从本规范中删除。[HTML30] 还建议了一个“版本”参数；实际上，该参数也从未使用过，并且已从本规范中删除。

这似乎是迄今为止最好的答案。

我将下面的原始答案留给后代。

---

概括

通过查看IETF和W3C以及 Internet 上其他地方的网站的RFC-2616（征求意见），似乎level没有很好地记录或解释该扩展。它似乎也没有被任何人用于标题中，这表明它可能会被忽略。

RFC

在 RFC 中，该level参数出现在一些示例中，但从未提及或明确表达过它所扮演的角色。

level在有关优先级的示例中使用：

媒体范围可以被更具体的媒体范围或特定媒体类型覆盖。如果多个媒体范围适用于给定类型，则最具体的引用具有优先权。例如，

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

具有以下优先级：

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

来源： IEFT RFC-2616 p.100和W3C RFC2616 部分“14.1 Accept”

看到两个示例中类型排序方式之间的差异，它的优先级似乎text/html;level=1高于text/html，这意味着level扩展必须赋予它该优先级。根据下降的特异性，最后两个显然是进一步排序的。

现在这带来了品质因数，q。它在 RFC 中得到了很好的解释。它可以是和之间01的任何东西。值越大，类型的优先级越高。RFC 有一个同时使用q和的示例level：

与给定类型相关联的媒体类型质量因子是通过查找与该类型匹配的具有最高优先级的媒体范围来确定的。例如，

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

将导致关联以下值：

    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 部分“14.1 Accept”

由此看来，level' 值用于降低优先级（1 具有最高优先级，2 次高，等等）。这是有道理的，但是当与Accept:标题一起使用时，它根本没有任何意义：

1. 首先，q参数已经从类型中神奇地消失了，在关联中（下图）。就像作者假设它们被省略的原因很明显，但忘记告诉我们为什么很明显。

2. 其次，Accept:标头中的类型和关联（如下）中显示的类型不是同一类型。例如，image/jpeg标题中从未提及类型，并且text/*关联中缺少类型。

我无法解释这一切意味着什么。

Zend 框架讨论

在回答有关level参数的问题时，有一些有趣的东西。

q并level互相恭维

[...] q 因子是最受关注的因子。但是，您也可以指定一个“级别”，这些 CAN 的行为也类似于优先级，但按照优先级递减的顺序进行操作（即，级别 1 的优先级高于级别 2）。他们在规范中的例子是人为的，而且，tbh，充其量是令人困惑的 [...]

q参数是你应该使用的，参数level是可以使用的。好的，但它仍然没有弄清楚它究竟做了什么，以及它应该如何影响类型的优先级。

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

“级别”的另一个记录用例是指示类型的_version_。例如，“级别 1”可能表示该规范的第一个可用版本。在这种情况下，它不是优先级，而是一个_descriptor_ [...]

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

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

然而，不知何故，我怀疑level应该用于此目的。如果是这样的话，它可能会被称为更具描述性的东西，例如version，或简单地v（例如q）。

相互矛盾的含义

不幸的是，“级别”选择器的含义相互矛盾，所以我不能 100% 确定我们应该默认支持它；另一方面，“q”是有据可查的。

是的。含义冲突，没有很好的记录。该level物业几乎没有什么用处。

我发现的其他东西

在互联网上的其他地方寻找问题/答案，我发现：

• 一份完全没有提及的严肃老派文件level。它实际上提到了另外两个，mxs和mxb。
• Moz Dev 页面列出Accept了来自各种浏览器的常见标头。无处level使用。事实上，我从未见过它在 RFC 之外使用过。

结论

总之，我认为可以肯定地说这level是浪费时间。它的文档记录很差，在实践中没有太多使用（如果使用的话），而且它比它的价值更令人困惑。

Answer 2

“级别”只是媒体类型参数的一个示例。它不参与计算偏好。

（现在的相关规范是http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#header.accept）

Answer 3

稍微扩展Julian Reschke 的正确答案。答案提到了直接来自规范的“媒体类型参数” ：

Accept = #( media-range [ accept-params ] )

     media-range    = ( "*/*" / ( type "/" "*" ) / ( type "/" subtype )) *( OWS ";" OWS parameter )
     accept-params  = weight *( accept-ext )
     accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

其中参数定义为：

parameter = token "=" ( token / quoted-string )

也就是说，一个名称/值对（参见token）。因此，在示例中，“level=1”只是合法“参数”的示例。从这个意义上说，它并没有什么特别之处。如果您花时间解析定义的 Backus-Naur，您会发现，在所有示例中，“level=x”必须是媒体类型参数。

关于示例为什么专门使用“级别”，我认为HTTP规范示例中的“级别”是指HTML级别。在所有示例中，level 修改了 text/html 媒体类型。我为 HTML 级别找到的最佳定义是：

“有四个官方级别 [0-4] 或 HTML 一致性版本。每个级别都包含一组标签，更高级别包括来自其以下所有标签的标签。”

http://scholar.lib.vt.edu/reports/soasis-slides/slide4.html

即，如果请求需要 HTML 元素/属性的子集，则可以使用 Accept 来请求较低级别的 HTML。例如，HTML 级别 0 定义了 DOCTYPE 元素，但直到级别 3 才定义“版本”属性；因此 HTML 级别 0-2 将/不应在<!DOCTYPE>声明中包含 Version 属性。

http://www.december.com/html/spec/level0.html

http://www.december.com/html/spec/level3.html

“级别”似乎是 HTML 的一个旧方面/功能。我可以找到很少的引用，没有一个是清楚的（例如，HTML 级别和主要版本之间有区别吗？），而且我能找到的大多数都是旧的。但是，最新的Apache httpd 服务器文档仍然说他们支持内容协商中的“级别”，并建议它可能与版本同义，至少在那个实现中：

“4.选择具有最高'级别'媒体参数的变体（用于给出文本/html媒体类型的版本）。”

请注意，IANA 注册中心没有提到任何关于“级别”作为 text/html 参数的内容。如果不出意外，那就是对我说：“不要使用它。”

有趣的是，DOM 规范仍然使用“级别”这个词。

http://www.w3.org/TR/DOM-Level-2-HTML/

http://www.w3.org/TR/DOM-Level-3-Core/

ETC..