HTTP是否接受“级别"? [英] HTTP Accept "level"?

问题描述

我一直在阅读 HTTP/1.1标头，并且在14.1节(接受)的某些示例标头中，它们使用称为 level = 1 的 accept-extension s(我相信这就是它们的意思)， level = 2 等

I have been reading up on the HTTP/1.1 headers and in some of the sample headers in section 14.1 (Accept) they use accept-extensions (I believe that is what they are) called level=1, level=2, etc.

我遇到的问题是他们使用这些 level = X 东西，好像他们所做的事情很明显一样.该文档只是难以解释，还是我遗漏了一些东西?

The problem I am having is that they use these level=X things as if it should be obvious what they do. Is the document just poor at explaining it or am I missing something?

谢谢.

推荐答案

...几年后

用户TomWardrop指出(从评论到此答案):

它曾经是text/html媒体类型规范的一部分，用于指示您想要的HTML版本，但是并没有使用太多(如果有的话)，因此已被删除.请参考 ietf.org/rfc/rfc2854.txt .

摘录自 RFC :

请注意，[HTML20]包含一个可选的级别"参数；在实际上，此参数从未使用过，并且已从中删除此规范.[HTML30]还建议使用版本"范围;实际上，此参数也从未使用过，并且具有已从该规范中删除.

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.

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

This appears to be the best answer so far.

我将以下原始答案留给后代.

I am leaving the original answer below for posterity.

它通过在 IETF 和

It appears from looking through RFC-2616 (Request For Comments) over at IETF and W3C, as well as websites elsewhere on the internet, that the level extension is not very well documented or explained. It also does not appear to be in use in headers by anyone, suggesting that it can probably be ignored.

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

In the RFCs the level parameter is seen in a few examples, but it is never mentioned or clearly expressed exactly what role it plays.

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, */*

具有以下优先级:

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

来源: IEFT RFC-2616第100页和 W3C RFC2616部分"14.1接受"

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

Seeing the difference between how the types are ordered in the two examples, it looks like text/html;level=1 has greater precedence than text/html, meaning that the level extension must give it that precedence. The last two are obviously ordered further, according to declining specificity.

现在，这将提出质量因子 q .在RFC中对此进行了很好的解释.可以是 0 和 1 代码> .值越大，类型的优先级越高.RFC有一个同时使用 q 和 level 的示例:

Now this brings up the quality factor, q. It is explained quite well in the RFCs. It can be anything between 0 and 1. The bigger the value the more precedence the type has. The RFC has an example using both q and 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

将导致以下值被关联:

    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第100页和 W3C RFC2616部分"14.1接受"

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

From this it appears that level's value is used in decreasing precedence (1 has highest precedence, 2 second highest, etc.). That makes sense, but when taken together with the Accept: header it makes no sense at all:

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

1. First, the q parameters have magically disappeared from the types, in the associations (below). It is like the author assumed that it is obvious why they have been omitted, but forgot to tell us why it is obvious.

第二， Accept:标头中的类型与关联(如下所示)中显示的类型不同.例如，标题中从未提及 image/jpeg 类型，并且关联中缺少 text/* 类型.

Second, the types in the Accept: header, and the types shown in the associations (below), are not the same types. E.g the image/jpeg type is never mentioned in the header, and the text/* type is missing from the associations.

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

I am at a loss to explain what it all means.

在

On an answer to a question asking about the level parameter there is some interesting stuff.

[...] q因子是最受关注的因子.但是，您也可以指定一个级别"，并且这些CAN也可以像优先级一样工作，但是按照优先级递减的顺序进行操作(即，级别1的优先级高于级别2).他们在规范中使用的示例都是人为设计的，而且，tbh充其量是令人困惑的[...]

[...] 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 参数 .好的，但是它仍然不能完全弄清它的作用以及它应该如何影响类型的优先级.

The q parameter is what you should use, and the level parameter can be used. Okay, but it still does not clear up exactly what it does, and how it is supposed to affect the priorities of types.

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

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_ [...]

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

So, a way of indicating what version of the type is supported. Now, this actually makes more sense:

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

以某种方式，我怀疑应该使用 level 来实现此目的.如果是这样的话，它可能会被称为更具描述性的名称，例如 version ，或者简称为 v (例如 q ).

Somehow I doubt level was supposed to be used for this, however. If it was then it would probably have been called something more descriptive, such as version, or simply v (like q).

不幸的是，级别"选择器的含义有冲突，因此我不确定100％是否默认支持该选择器.另一方面，"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 属性几乎没有用.

Yeah. Conflicting meanings and not very well documented. The level property has very little going for it.

在Internet上其他地方寻找问题/答案

Looking for questions/answers elsewhere on the Internet I found:

• 严重的老式文档，其中没有提到级别完全没有.实际上，它还提到了另外两个， mxs 和 mxb .
• 一个 Moz开发人员页面列出了各种常见的 Accept 标头浏览器.没有在任何地方使用 level .实际上，我从未见过它在RFC之外使用.

• A seriously old-school document that does not mention level at all. It actually mentions two other ones, mxs and mxb.
• A Moz Dev page listing common Accept headers from various browsers. Nowhere is level used. In fact, I have never seen it used outside the RFCs.

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

In conclusion I think it is safe to say that level is a waste of time. It is poorly documented, not used much in practice (if used at all), and it is more confusing than it is worth.

这篇关于HTTP是否接受“级别"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！