HTTP接受"级别"?

Sve*_*sen 8 http

我一直在读了HTTP/1.1头和一些在14.1节(接受)他们使用的样本头accept-extension秒(我相信这是它们是什么)呼吁level=1,level=2等等.

我遇到的问题是他们使用这些level=X东西就好像它们应该是显而易见的.该文件是否很难解释它或我错过了什么?

谢谢.

Sve*_*sen 9

几年后的几年

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

它用作text/html媒体类型规范的一部分,以指示你想要的HTML版本,但是没有使用太多(如果有的话),所以它被删除了.请参阅ietf.org/rfc/rfc2854.txt.

RFC的摘录:

请注意,[HTML20]包含可选的"级别"参数; 在实践中,此参数从未使用过,并已从此规范中删除.[HTML30]还提出了"版本"参数; 在实践中,此参数也从未使用过,并已从此规范中删除.

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

我将在下面留下原始答案给后人.


摘要

通过在IETFW3C以及互联网上其他地方的网站上查看RFC-2616(征求意见请求),可以看出该level扩展没有很好地记录或解释.任何人似乎都没有在标题中使用它,这表明它可能会被忽略.

RFC

在RFC中,level参数在几个示例中可见,但从未提及或明确表达它所扮演的角色.

level 用于关于优先级的示例:

媒体范围可以被更具体的媒体范围或特定媒体类型覆盖.如果给定类型应用多个介质范围,则最具体的引用优先.例如,

    Accept: text/*, text/html, text/html;level=1, */*
Run Code Online (Sandbox Code Playgroud)

具有以下优先顺序:

    1) text/html;level=1
    2) text/html
    3) text/*
    4) */*
Run Code Online (Sandbox Code Playgroud)

来源:IEFT RFC-2616 p.100W3C RFC2616部分"14.1接受"

看到两个示例中的类型排序方式之间的区别,它看起来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
Run Code Online (Sandbox Code Playgroud)

会导致以下值关联:

    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
Run Code Online (Sandbox Code Playgroud)

来源:IEFT RFC-2616 p.100W3C RFC2616部分"14.1接受"

从这看起来,它level的值用于递减优先级(1具有最高优先级,2秒具有最高优先级等).这是有道理的,但是当与Accept:标题一起使用时根本没有意义:

  1. 首先,q参数在类型中,在协会(下面)中神奇地消失了.就像作者认为很明显为什么它们被省略,但忘了告诉我们为什么它是显而易见的.

  2. 其次,Accept:标题中的类型和关联中显示的类型(如下所示)不是相同的类型.例如,image/jpeg标题中从未提及类型,并且text/*关联中缺少类型.

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

Zend框架讨论

关于询问level参数的问题答案,有一些有趣的东西.

qlevel互相称赞

[...] q因子是最受关注的因素.但是,您也可以指定"级别",这些CAN也可以像优先级一样运行,但按优先级递减的顺序运行(即,级别1优先级高于级别2).他们在规范中的例子是人为的,而且,最好让人感到困惑[...]

q参数是您应该使用的level参数,可以使用该参数.好的,但它仍然没有完全清楚它的作用,以及它应该如何影响类型的优先级.

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

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

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

text/html;level=5;q=1
text/html;level=4.01;q=0.9
; Etc.
Run Code Online (Sandbox Code Playgroud)

但不知何故,我怀疑level应该用于此目的.如果它是那么它可能会被称为更具描述性的东西,例如version,或简单v(像q).

矛盾的意义

不幸的是,"级别"选择器具有相互矛盾的含义,所以我不是100%肯定我们应该默认支持它; 另一方面,"q"有很好的记录.

是啊.冲突的意义并没有很好的记录.该level物业很少有它.

我找到的其他东西

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

  • 一个严重的老式文件,根本没有提到level.它实际上提到了另外两个,mxs并且mxb.
  • 万盎司开发页面列出常见的Accept各种浏览器的标题.无处level使用.事实上,我从未见过它在RFC之外使用过.

结论

总之,我认为可以说这level是浪费时间.它的记录很少,在实践中使用不多(如果使用的话),它比它的价值更令人困惑.

  • 这是不正确的."level"只是媒体类型参数的一个示例.它不参与计算偏好. (3认同)

Jul*_*hke 5

"level"只是媒体类型参数的一个示例.它不参与计算偏好.

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

  • 为了澄清,"level"只是在RFC中用作占位符?换句话说,它也可能是其他东西,例如`audio/mpeg; bitrate = 256; q = 1,audio/mpeg; bitrate = 128; q = 0.9`? (2认同)