私はHTTP/1.1 ヘッダーについて調べており、セクション 14.1 (Accept) のいくつかのサンプル ヘッダーでは、、 などaccept-extensionと呼ばれる s (それがそうだと思います) を使用しています。level=1level=2
私が抱えている問題は、彼らがこれらのlevel=Xことをあたかも彼らが何をしているのか明らかであるべきであるかのように使用していることです. ドキュメントの説明が下手なだけですか、それとも何か抜けているのでしょうか?
ありがとう。
ユーザー TomWardrop は次のことを指摘しています (コメントからこの回答へ):
これは、必要な HTML のバージョンを示すための text/html メディア タイプ仕様の一部でしたが、あまり使用されていなかった (使用されたとしても) ため、削除されました。ietf.org/rfc/rfc2854.txtを参照してください。
RFCからの抜粋:
[HTML20] にはオプションの「レベル」パラメータが含まれていることに注意してください。実際には、このパラメータは使用されておらず、この仕様から削除されています。[HTML30] も「バージョン」パラメータを提案しました。実際には、このパラメーターも使用されることはなく、この仕様から削除されました。
これは、これまでのところ最良の答えのようです。
後世のために元の回答を以下に残します。
IETFやW3Cの RFC-2616 (Request For Comments)や、インターネット上の他の Web サイトを調べてみると、この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 セクション「14.1 Accept」
2 つの例での型の順序付けの違いを見ると、text/html;level=1よりも優先順位が高いように見えます。text/htmlつまり、level拡張機能がその優先順位を与える必要があることを意味します。特異性の低下によると、最後の 2 つは明らかにさらに順序付けられています。
これにより、品質係数 が表示されます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 が 2 番目に高いなど)。それは理にかなっていますが、ヘッダーと一緒にAccept:考えるとまったく意味がありません:
まず、q関連 (下記) で、パラメーターが型から魔法のように消えてしまいました。著者は、それらが省略された理由は明らかだと思い込んでいたようですが、なぜそれが明らかなのかを説明するのを忘れていました。
第 2 に、Accept:ヘッダー内の型と、関連付け (下記) に示されている型は同じ型ではありません。たとえば、image/jpegタイプがヘッダーに記載されておらず、text/*タイプが関連から欠落しています。
私はそれが何を意味するのかを説明するのに途方に暮れています。
パラメータについて尋ねる質問への回答に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.Acceptどこにもlevel使用されていません。実際、RFC 以外で使用されているのを見たことがありません。level結論として、それは時間の無駄だと言って間違いないと思います。文書化が不十分で、実際にはあまり使用されておらず (使用されたとしても)、価値があるよりも混乱しています。
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 レベルの最適な定義は次のとおりです。
「4 つの公式レベル [0-4]、または HTML 準拠のバージョンがあります。各レベルには一連のタグが含まれ、上位レベルにはその下のすべてのタグが含まれます。」
http://scholar.lib.vt.edu/reports/soasis-slides/slide4.html
つまり、HTML 要素/属性のサブセットが必要な場合、要求は Accept を使用して下位レベルの HTML を要求できます。例として、HTML レベル 0 は DOCTYPE 要素を定義しますが、レベル 3 まで「バージョン」属性を定義しません。<!DOCTYPE>HTML レベル 0 ～ 2 では、宣言に Version 属性を含める必要があります。
http://www.december.com/html/spec/level0.html
http://www.december.com/html/spec/level3.html
「レベル」はHTMLの古い側面/機能のようです。私はそれへの参照をほとんど見つけることができず、どれも明確ではありません (例えば、HTML レベルとメジャー バージョンに違いはありますか?)、そして私が見つけることができるもののほとんどは古いものです。ただし、最新の Apache httpd サーバーのドキュメントでは、コンテンツ ネゴシエーションで「レベル」をサポートしているとまだ述べており、少なくともその実装ではバージョンと同義である可能性があることを示唆しています。
「4. 最高の「レベル」メディア パラメータ (text/html メディア タイプのバージョンを指定するために使用) を持つバリアントを選択します。」
IANA レジストリは、text/html パラメータとしての「レベル」について何も言及していないことに注意してください。他に何もないとしても、それは私に言います：「それを使用しないでください」。
興味深いことに、DOM 仕様ではまだ「レベル」という言葉が使用されています。
http://www.w3.org/TR/DOM-Level-2-HTML/
http://www.w3.org/TR/DOM-Level-3-Core/
等..