水無月ばけらのえび日記

某所では「クライアント側でやってるのと同じチェックをなぜかサーバ側でもやってる。まったくの無駄」とかいう会話が隣の席から聞こえてきて、めまいがしてきます。

> ※が、どこかの脚注に「IEのAccept:は長すぎて無駄」みたいな記述があり、コンテント・ネゴシエーションがイマイチ理解されていない気配も……。

これですね。

P.287より

> Internet Explorer 6が送信するAcceptヘッダで、許可されるMIMEタイプのリストを長々と記述したあげく最後に */* を付けるのは、奇妙というしかない。*/* という値は、任意のMIMEタイプを受け付けるということを意味する。したがって、「image/gif, image/jpeg, ... , */*」というリストはばかげていて冗長である。「無限大+1」といい勝負である。

優先順位の指定ができることを理解していないことは明らかです。

それはそれとして、個人的には今話題の「ホワイトリスト形式の入力チェック」が連呼されている方が気になります。

> 優先順位の指定ができることを理解していないことは明らかです。

「qvalueを使わなくても」と言っておかないと「優先順位の指定ができるのにやってないMicrosoftのことですね、わかります」とか早とちりされそうな気のせいがします。

http://www.ietf.org/rfc/rfc2616.txt

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

>

> have the following precedence:

>

> 1) text/html;level=1

> 2) text/html

> 3) text/*

> 4) */*

ただ、この直後に続く文章と併せて読むと、"precedence"はクライアントが好むMIMEタイプの優先順位ではなく、qvalue決定のためにリストを検索する順序の決定に用いられるものであるように読めるのが気になるのですが…。

>ただ、この直後に続く文章と併せて読むと、"precedence"はクライアントが好むMIMEタイプの優先順位ではなく、qvalue決定のためにリストを検索する順序の決定に用いられるものであるように読めるのが気になるのですが…。

最終的なメディアタイプの決定にqvalueだけを使用すると、意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、優先順位も加味しないとうまく行かない感じがします。とはいえ最終的なメディアタイプの決定方法が仕様として明示されていないのであれですが。そもそも記述順＝優先順位ということすら明示されていないような。

> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、優先順位も加味しないとうまく行かない感じがします。

だから元記事では冗長だと言っているのでは? そうなるとRFCに「無意味」な例が載せられていることになるので妙と言えば妙ですが。

> とはいえ最終的なメディアタイプの決定方法が仕様として明示されていないのであれですが。

「*/*」だけが指定されたときとかそもそも指定されていないときとかも決定できないと困りますから、優先順位の同じものが並んでいたら別途定める決定方法を採用してもかまわないのだと思います。

> そもそも記述順＝優先順位ということすら明示されていないような。

詳細度やqvalueの高いMIMEタイプ指定を後に行うことも可能なので明らかに記述順は優先順位と異なるでしょう。RFCの例もそうなっています。

> だから元記事では冗長だと言っているのでは? そうなるとRFCに「無意味」な例が載せられていることになるので妙と言えば妙ですが。

そこまでRFCを読み込んでいるなら曖昧なRFCの方を批判しそうな気がしますが、「悪いのはMS」脳になっているのかもしれません。

> 「*/*」だけが指定されたときとかそもそも指定されていないときとかも決定できないと困りますから、優先順位の同じものが並んでいたら別途定める決定方法を採用してもかまわないのだと思います。

別途定める決定方法の採用が可能であれば、RFCのあの部分の内容は、特定のタイプに対応するqvalueの決定方法というだけの事になるので、qvalueのみで採用するタイプを決定しなければならない訳ではないということになるかと思います。

ちなみにRFCから察する限り、優先順位は一次元配列内の位置として表されるので、同じ優先順位のものが存在することはないはずです。

> 詳細度やqvalueの高いMIMEタイプ指定を後に行うことも可能なので明らかに記述順は優先順位と異なるでしょう。RFCの例もそうなっています。

「Media ranges can be overridden by more specific media ranges or specific media types.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

>別途定める決定方法の採用が可能であれば、RFCのあの部分の内容は、特定のタイプに対応するqvalueの決定方法というだけの事になるので、qvalueのみで採用するタイプを決定しなければならない訳ではないということになるかと思います。

qvalueは同じ値になることもあるのでqvalueのみで決定しなければならない訳ではないことは明らかだと思います。ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

>ちなみにRFCから察する限り、優先順位は一次元配列内の位置として表されるので、同じ優先順位のものが存在することはないはずです。

それは

>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

>「Media ranges can be overridden by more specific media ranges or specific media types.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

> ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

結局、エンティティの決定方法は「12 Content Negotiation」にも定義されていないので、どんな決定方法を取ってもRFCに則していないことにはならないと思います。たとえば「サーバのお薦め」みたいなサーバ都合の評価軸も持つアルゴリズムにしている場合、正当な理由でqvalueの大小が無視されるという状況を発生させることができそうな気がします。とはいえ「サーバのお薦め」ってなんだか分かりませんが、よりヒットしているキャッシュの方とか?

>>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

> とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

それはqvalueのみを条件に使う場合というコンテキストでのみ成り立つ文なので、お察しください(謎)。

> それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

自明であるはずのAcceptフィールドの優先順位すら明確に察せない私は、まだまだ察しスキルが足りないということなのでしょう(謎)。