新生鳩丸掲示板♯

> だから元記事では冗長だと言っているのでは? そうなると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.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

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

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

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

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

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

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

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

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

某大臣の舌禍事件といい、アメリカ大統領選といい、平壌放送といい、政治と扇動って切って切れない関係にあることを痛感しますね。

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

「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決定のためにリストを検索する順序の決定に用いられるものであるように読めるのが気になるのですが…。

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

これですね。

P.287より

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

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

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

1年以上前の記事なので、あれなんですけどワタシも今同じ症状になって検索でHITしました（ｗ

同じくヘッドホン端子抜いても音でなくなり、壊れた～！と思っていたら

何度か刺しなおしたり、つまようじでイジったら音出ました（ｗ

ちなみに旧ＤＳです。

いやー、焦りますね（ｗ

では（ｗ

Googleならば、当然の如くリファラも記録しているのではないでしょうか？

ソースはありませんが、以前自分だけが使用していたWebページが

Googleからの検索にヒットするようになり驚いたことがあります。

特に認証等は設けておらず、また(当時はありませんでしたが)オンラインブックマークサービスや、

URLを別のWebサイトに載せることもしていませんでした。

考えてたどり着いたのが、そのWebサイトにリンクとして載せていた

Google検索ページのURLでした。

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

ぜひ「パナソニック政経塾」を :-)。

しかし、パナソニックの便器

http://panasonic.jp/sumai/toilet/

というのも違和感大きいですなぁ…。

ATOK使っているのであれば「きょう」で変換するとかどうでしょう？

# MS-IMEは対応していたか忘れました。

>　なるほど、Browser Object Model ですか。

>　暇を見て追加しておきます。

ありがとうございます！（汗

>「2006-10-01追記」となっているようですが、「2008-10-01追記」ではないでしょうか。

　はぅ、おっしゃるとおりです。ありがとうございます。

　修正しておきました。

> ……結論としては、このマンガは面白いということですよ!

思わず買ってしまったではありませんか。おもしろかったです。Web上の書評につられて本を買ったのは初めてかも。amazonアソシエイト経由ではなくて申し訳ありませんが。

「2006-10-01追記」となっているようですが、「2008-10-01追記」ではないでしょうか。

>http://bakera.jp/ebi/topic/2738 の下のほうでしょうか。

それですね。私の探し方が悪かったようです。ありがとうございました。

>鳩丸ぐろっさり（用語集）には、すでにBOMに関する記述があります。byte order mark としての BOM の他に、object model としての BOM もあろうかとは思うのですが、もしよろしければ、記事の追加をお願いできませんでしょうか。

　なるほど、Browser Object Model ですか。

　暇を見て追加しておきます。

WebプログラマーはURLは公開情報である。(それは例えSSLであっても)と、意識して欲しいと思います。

ちなみに、3年前から固定URLだったというコメントが/.に出ています。

slashdot.jp/security/comments.pl?sid=420884&cid=1429623

# 日曜Webプログラマだけどセキュリティホール情報にアンテナを張って保守を頑張ってるのでID

鳩丸ぐろっさり（用語集）には、すでにBOMに関する記述があります。byte order mark としての BOM の他に、object model としての BOM もあろうかとは思うのですが、もしよろしければ、記事の追加をお願いできませんでしょうか。　ひょっとしたらぐろっさりの範疇外かもしれませんけれども、その際には上のお願いは撤回いたします。

以上、よろしくお願い申し上げます。

>以前このサイトで「常に妥当なHTMLを出力するようにすればXSSの9割は防げる」というような発言を見たような気がするのですが、日記を検索してもぐろっさりをたどっていってもそのような文章が見つかりません。

http://bakera.jp/ebi/topic/2738 の下のほうでしょうか。