我一直在阅读HTTP/1.1 headers和第14.1节（接受）中的一些示例标题，他们使用accept-extension（我相信它们就是这样）{{1} }，level=1等
我遇到的问题是他们使用这些level=2的东西，好像它们应该是显而易见的。该文件是否很难解释它或我遗失了什么？
感谢。
答案 0 :(得分：8)
用户TomWardrop指出（从评论到此答案）：
它用于成为text / html媒体类型规范的一部分，以指示您想要的HTML版本，但是它没有被大量使用（如果有的话），所以它被删除了。请参阅ietf.org/rfc/rfc2854.txt。
摘自the RFC：
请注意，[HTML20]包含一个可选的＆＃34;级别＆＃34;参数;在 实践中，此参数从未使用过并已从中删除 这个规范。 [HTML30]也提出了一个＆＃34;版本＆＃34; 参数;在实践中，这个参数也从未使用过 已从此规范中删除。
到目前为止，这似乎是最好的答案。
我将以下原始答案留给后人。
通过查看IETF和W3C以及互联网上其他网站的RFC-2616（征求意见请求），level扩展名不是很记录或解释。任何人似乎都没有在标题中使用它，这表明它可能会被忽略。
在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 section "14.1 Accept"
在两个示例中看到类型的排序方式之间的区别，看起来text/html;level=1的优先级高于text/html，这意味着level扩展必须赋予它优先级。根据特异性下降，最后两个显然是进一步排序。
现在这会带来品质因素q。它在RFC中得到了很好的解释。它可以是任何between 0 and 1。值越大，类型的优先级越高。 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 section "14.1 Accept"
由此看来，level的值用于降低优先级（1具有最高优先级，2秒具有最高等等）。这是有道理的，但是当与Accept:标题一起使用时根本没有任何意义：
首先，q参数在类型，关联（下方）中神奇地消失了。就像作者认为很明显为什么它们被省略，但忘了告诉我们为什么它是显而易见的。
其次，Accept:标题中的类型以及关联中显示的类型（如下所示）的类型不同。例如，标题中从未提及image/jpeg类型，并且关联中缺少text/*类型。
我无法解释这一切意味着什么。
在answer to a question asking about the level parameter上有一些有趣的东西。
q和level相互称赞[...] q因子是最受关注的因素。但是，您也可以指定＆＃34;级别＆＃34;，这些CAN也可以像优先级一样运行，但按优先级递减的顺序运行（即，级别1的优先级高于级别2）。他们在规范中的例子是人为的，而且，最好让人感到困惑[...]
您应该使用q参数，并且可以使用level参数 。好的，但它仍然没有完全清楚它的作用，以及它应该如何影响类型的优先级。
＆＃34;等级的另一个记录用例＆＃34;是指示类型的_version_。例如，＆＃34; 1级＆＃34;可能表示该规范的第一个版本可用。在这种情况下，它不是优先事项，而是_descriptor_ [...]
因此，一种指示支持版本类型的方式。现在，这实际上更有意义：
text/html;level=5;q=1
text/html;level=4.01;q=0.9
; Etc.
level应该用于此。如果是，那么它可能会被称为更具描述性的内容，例如version，或仅v（如q）。
不幸的是，＆＃34;等级＆＃34;选择器具有相互矛盾的含义，所以我不能100％确定我们应该默认支持它;另一方面，＆＃34; q＆＃34;已有详细记录。
呀。冲突的意义并没有很好的记录。 level属性几乎没有。
在互联网上的其他地方寻找问题/答案我发现：
level。它实际上提到了另外两个，mxs和mxb。Accept标头。无处使用level。事实上，我从未见过它在RFC之外使用过。总之，我认为可以说level是浪费时间。它的记录很少，在实践中没有太多用处（如果使用的话），它比它的价值更令人困惑。
答案 1 :(得分：5)
“level”只是媒体类型参数的一个示例。它没有参与计算偏好。
（现在的相关规范是http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#header.accept）
答案 2 :(得分：4)
稍微扩展Julian Reschke's correct answer。答案提到＆＃34;媒体类型参数＆＃34;直接来自the specification：
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定义为：
parameter = token "=" ( token / quoted-string )
即名称/值对（请参阅token）。因此，在示例中，＆＃34; level = 1＆＃34;只是 法律＆＃34;参数＆＃34;的例子。从这个意义上说，没有什么特别之处。如果您花时间解析定义的Backus-Naur，您会在所有示例中看到＆＃34; level = x＆＃34; 必须是媒体类型参数。
关于为什么该示例专门使用＆＃34; level＆＃34;，我认为＆＃34;等级＆＃34;在HTTP规范中，示例涉及HTML级别。在所有示例中，level修改text / html媒体类型。我发现HTML级别的最佳定义是：
＆＃34;有四个官方级别[0-4]或HTML一致性版本。每个标签都包含一组标签，更高级别包含来自其下方所有标签的标签。＆＃34;
http://scholar.lib.vt.edu/reports/soasis-slides/slide4.html
即，如果需要HTML元素/属性的子集，请求可以使用Accept来请求较低级别的HTML。例如，HTML级别0定义DOCTYPE元素，但不定义＆＃34;版本＆＃34;属性直到3级;这样HTML级别0-2将/不应包含<!DOCTYPE>声明中的Version属性。
http://www.december.com/html/spec/level0.html
http://www.december.com/html/spec/level3.html
＆＃34;电平＆＃34;看起来像HTML的旧方面/功能。我可以找到很少的引用，没有一个是清楚的（例如，HTML级别和主要版本之间有区别吗？），我发现的大多数都是旧的。但是， latest Apache httpd server docs仍然表示他们支持＆＃34;等级＆＃34;在内容协商中，并建议它可能与版本同义，至少在该实现中是这样的：
＆＃34; 4。选择最高级别的变体＆＃39; media参数（用于提供text / html媒体类型的版本）。＆＃34;
请注意，IANA registry并未提及＆＃34; level＆＃34; 作为text / html参数的任何内容。如果没有别的，那就告诉我：＆＃34;不要使用它。＆＃34;
有趣的是，DOM规范仍然使用＆＃34; level＆＃34;。
这个词http://www.w3.org/TR/DOM-Level-2-HTML/
http://www.w3.org/TR/DOM-Level-3-Core/
等。