...数年後
ユーザー TomWardrop は次のことを指摘しています (コメントからこの回答へ):
これは、必要な HTML のバージョンを示すための text/html メディア タイプ仕様の一部でしたが、あまり使用されていなかった (使用されたとしても) ため、削除されました。ietf.org/rfc/rfc2854.txtを参照してください。
RFCからの抜粋:
[HTML20] にはオプションの「レベル」パラメータが含まれていることに注意してください。実際には、このパラメータは使用されておらず、この仕様から削除されています。[HTML30] も「バージョン」パラメータを提案しました。実際には、このパラメーターも使用されることはなく、この仕様から削除されました。
これは、これまでのところ最良の答えのようです。
後世のために元の回答を以下に残します。
概要
IETFやW3Cの RFC-2616 (Request For Comments)や、インターネット上の他の Web サイトを調べてみると、この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」
2 つの例での型の順序付けの違いを見ると、text/html;level=1
よりも優先順位が高いように見えます。text/html
つまり、level
拡張機能がその優先順位を与える必要があることを意味します。特異性の低下によると、最後の 2 つは明らかにさらに順序付けられています。
これにより、品質係数 が表示されますq
。それはRFCで非常によく説明されています。から までの任意の値を指定できます0
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 セクション「14.1 Accept」
このことから、level
の値は優先順位を下げるために使用されているように見えます (1 が最も優先順位が高く、2 が 2 番目に高いなど)。それは理にかなっていますが、ヘッダーと一緒にAccept:
考えるとまったく意味がありません:
まず、q
関連 (下記) で、パラメーターが型から魔法のように消えてしまいました。著者は、それらが省略された理由は明らかだと思い込んでいたようですが、なぜそれが明らかなのかを説明するのを忘れていました。
第 2 に、Accept:
ヘッダー内の型と、関連付け (下記) に示されている型は同じ型ではありません。たとえば、image/jpeg
タイプがヘッダーに記載されておらず、text/*
タイプが関連から欠落しています。
私はそれが何を意味するのかを説明するのに途方に暮れています。
Zend フレームワークのディスカッション
パラメータについて尋ねる質問への回答にlevel
は、いくつかの興味深いものがあります。
q
そしてお互いをlevel
褒め合う
[...] q ファクターは、最も注目されているものです。ただし、「レベル」を指定することもできます。これらの CAN も優先度のように機能しますが、優先度の低い順に動作します (つまり、レベル 1 はレベル 2 より優先度が高くなります)。彼らが仕様に持っている例は不自然であり、せいぜい紛らわしい[...]
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
。実際には、他に 2 つ、mxs
およびmxb
.
- さまざまなブラウザーの共通ヘッダーを一覧表示するMoz Dev ページ。
Accept
どこにもlevel
使用されていません。実際、RFC 以外で使用されているのを見たことがありません。
結論
level
結論として、それは時間の無駄だと言って間違いないと思います。文書化が不十分で、実際にはあまり使用されておらず (使用されたとしても)、価値があるよりも混乱しています。