アカウント名:
パスワード:
XMLのファイルをアップロード/ダウンロードするようなソフトを作っているときに大ハマりしました。
どうも、IEは
という順序でファイルをどう扱うかを決めているような気配があります。
XMLファイルをディスクにセーブさせたいので、拡張子は(ファイルタイプとして登録されていない)適当なものにして、Content-TypeをApplication/Octet-StreamなどにしてもXMLとして表示してくれるという大きなお世話を焼いてくれたと記憶しています。
ほとんどは拡張子かファイルの中身で処理方法は決まってしまうわけで、Content-Typeを無視するというのはあながち間違っていないんじゃないでしょうか。
どうも、IEは (中略) という順序でファイルをどう扱うかを決めているような気配があります。
最終的に text/html だろうが audio/wav だろうが PIF だろうが SCR だろうが (以下略)、Windows が「実行」(というか default のメソッドを選択する) 事に問題があるんではありませんかね?
そうでなければ拡張子を見て云々なんてする仕様を考えなきゃいけない必然性がありませんから。
どちらかっつうと、Content-Type で「のみ」判断すべきであって、
これは全くその通りですね。
拡張子(という言い方もローカルなんだが)とファイルの性質の対応(*.exeが実行ファイルで、*.docがMS-Wordのファイル、など)はWindowsの世界に限られたローカルなルールであるのに対し、Content-Typeでファイルの性質を表すというのはプラットフォームに依らないグローバルなルールです。IEの挙動はプラットフォームによらないルールをぶち壊して自分のルールを押しつけようとしていると言えます。Windowsと違う拡張子の使い方をするな、と言っているようにすら感じます。
Webサーバの設定が不適切でバイナリファイルをtext/plainにしてしまっているサイトは多いのですが、それはまた別の問題ですね。もっともどのブラウザもContent-Typeに忠実に表示するようになっていたらサーバ管理者もすぐミスに気づくでしょうが。
拡張子に相当する部分のないURLに、XHTML文書を置くと、XMLツリーが表示されてしまう事があります。Accept:にapplication/xml+xhtml等が無いので、IEはXHTMLを知らない、と見なすのが適切かもしれませんが。
IEのコンポーネントの他にも、ファイルタイプの決定に関わっている部分がある様で、IEのビルド番号とOSの組み合わせが同じでもHTMLと認識される環境とXMLツリーが表示される環境があります。
ファイルの中身を見てくれるお陰で、拡張子やContent-Typeが誤っている画像ファイル等をうまく表現出来たりするのですが、その所為で正しい記述を勘違いするのは大き過ぎる代償。
ファイルタイプ決定のプロセスに、付け加えると、
かな。
http://とfile://を似た様な物とし過ぎているのがいけません。
とか。
飽くまで、ローカルのファイルシステムを用いて、ローカルな環境の流儀に則ってブラウズする為の物で、その点はIEも外していないと思います(嫌な流儀かもしれないけど)。
こう書いたら、IEは、fileスキーマを拡張してhttpスキーマを実装している様にも思えるなあ……。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Online Solutions 社によると (スコア:1)
Re:Online Solutions 社によると (スコア:0)
Re:Online Solutions 社によると (スコア:1)
画面でファイルの処遇を聞いてくるときの表示に使っている。
# と思われる節がある
audioだと思って開いてみたら・・・・
ファイルをその後「WinExec」してるんじゃなかろうかと。
そら、あきまへんって
拡張子pifの音楽ファイルなんてないないscrもな
NimdaとかAlizとか、TransBってこれ利用してるんだから
既知の問題じゃないの?
Re:Online Solutions 社によると (スコア:3, 参考になる)
Nimdaなどには感染したことがないので推測ですが、スクリプトやIFRAMEを使った処理の場合、ダイアログは(デフォルトのインターネットゾーンの設定では)表示されないので、気づかずに処理が行われてしまう…のですよね?そういう意味で、ダイアログでユーザーをだまして信頼させてしまえる今回の脆弱性は新しいものでしょう。
Re:Online Solutions 社によると (スコア:1)
2. 「開く」を指定するとダウンロードが行われ、サーバ上の実際のファイル名でファイルが保存される
Re:Online Solutions 社によると (スコア:1)
RE: File extensions spoofable in MSIE download dialog [ryukoku.ac.jp]
Re:Online Solutions 社によると (スコア:1)
XMLのファイルをアップロード/ダウンロードするようなソフトを作っているときに大ハマりしました。
どうも、IEは
という順序でファイルをどう扱うかを決めているような気配があります。
XMLファイルをディスクにセーブさせたいので、拡張子は(ファイルタイプとして登録されていない)適当なものにして、Content-TypeをApplication/Octet-StreamなどにしてもXMLとして表示してくれるという大きなお世話を焼いてくれたと記憶しています。
ほとんどは拡張子かファイルの中身で処理方法は決まってしまうわけで、Content-Typeを無視するというのはあながち間違っていないんじゃないでしょうか。
Re:Online Solutions 社によると (スコア:3, すばらしい洞察)
何かある毎に手探りで想像しなきゃいかんってのは非生産的過ぎ。
Re:Online Solutions 社によると (スコア:1)
別件で調べ物をしていて偶然知ったのですが、公開されてるようですよ。
Appendix A: MIME Type Detection in Internet Explorer [microsoft.com]
Re:Online Solutions 社によると (スコア:2)
でも深いところにあるなあ....
Re:Online Solutions 社によると (スコア:1)
みんつ
Re:Online Solutions 社によると (スコア:2)
最終的に text/html だろうが audio/wav だろうが PIF だろうが SCR だろうが (以下略)、Windows が「実行」(というか default のメソッドを選択する) 事に問題があるんではありませんかね?
そうでなければ拡張子を見て云々なんてする仕様を考えなきゃいけない必然性がありませんから。
Re:Online Solutions 社によると (スコア:1)
まったくその通りだと思います。
デフォルトの動作は、非破壊的(ユーザーの何らかの情報を失わせたり変化させたりしない)
かつ非窃盗的(ユーザーの何らかの情報を外界にコピーしない)な、
たぶん「閲覧」とでも呼ばれるべきメソッドに、しておくべきです。
仕事でここ数年、某OODB+それ用のGUIクライアントを扱っているんですが、
こいつのクライアントでObject(を現すアイコン)をダブルクリック(など)をしたときに、
そういう意味で破壊的な動作をデフォでするようなデータクラスは、
最初から存在しないし、我々のカスタマイズでも作ったこと有りません。
誰も(客も我々も)考えたこともないですね、破壊的動作を割り当てようなんてことは。
そんな危なっかしくて使いにくいもの、誰も望みませんって。
イントラネットな世界ですらこうなのに、なんでインターネットばりばりなWindowsが
こんな阿呆な仕様がデフォなんでしょう?
Re:Online Solutions 社によると (スコア:3, すばらしい洞察)
更にそういう人は OK 押すのも面倒がるから始めっから実行にしとけと思っている
....と MS が思っているからじゃないですかねぇ。
コンピュータのコンピュータ処理の部分をユーザから隠す行為自体はユーザビリティ
もあるので基本的にはさほど反対したくないんですが、だったら本当にユーザが
何もしなくても安全で幸せに使えるようになっていないと駄目なわけで、現状ではまだまだですね。
せめてオプションで設定を変えられるとかすればいいと思うんだけど。上級者用、かなんかのラベルつけて。
Re:Online Solutions 社によると (スコア:2, 興味深い)
インターネットエクスプローラーであると同時に、Windowsのシェルであるエクスプローラーである、っていうのが諸悪の根元かと。
共通のエンジンを使い、なおかつインターネット用にセキュリティを強化してない。
(単なる手抜きですね。)
結果として、IEはブラウザではなく、(場合によってはリモート操作可能な)ファイルマネージャーになってしまっている。
手抜きの結果、全く別なソフトになってしまってますね。(^_^;)
と、ここまで書いてこれ [bbc.co.uk]を思い出した。
「製品を低コストで提供することで成功したんだ。」 = 「手間をかけていない粗悪品を売りつけることに成功したんだ。」という意味なのかな。
ファイルタイプはContent-Typeで判断すべき (スコア:2)
これは全くその通りですね。
拡張子(という言い方もローカルなんだが)とファイルの性質の対応(*.exeが実行ファイルで、*.docがMS-Wordのファイル、など)はWindowsの世界に限られたローカルなルールであるのに対し、Content-Typeでファイルの性質を表すというのはプラットフォームに依らないグローバルなルールです。IEの挙動はプラットフォームによらないルールをぶち壊して自分のルールを押しつけようとしていると言えます。Windowsと違う拡張子の使い方をするな、と言っているようにすら感じます。
Webサーバの設定が不適切でバイナリファイルをtext/plainにしてしまっているサイトは多いのですが、それはまた別の問題ですね。もっともどのブラウザもContent-Typeに忠実に表示するようになっていたらサーバ管理者もすぐミスに気づくでしょうが。
Re:Online Solutions 社によると (スコア:1)
「Content-Typeを後回しにする」仕様はダメダメだというのは私もそう思ってます。
#46179で「無視はしない」と書かれているので、「現実には無視してるも同然だよ」といいたかったわけで。
読み返してみたら、「Content-Typeを無視するのは理にかなってる」としか読めねーんでやんの(笑) > 自分の#46195
私もそうかとおもっていましたが (スコア:1)
contentType='application/octet-stream';
Response.AddHeader('Content-Disposition',"attachment; filename=hoge.xml");
で、強制ダウンロードできましたよ?
raspy
訂正。。。 (スコア:1)
Response.ContentType='application/octet-stream';
ですね。すいません
raspy
Re:Online Solutions 社によると (スコア:1)
拡張子に相当する部分のないURLに、XHTML文書を置くと、XMLツリーが表示されてしまう事があります。Accept:にapplication/xml+xhtml等が無いので、IEはXHTMLを知らない、と見なすのが適切かもしれませんが。
IEのコンポーネントの他にも、ファイルタイプの決定に関わっている部分がある様で、IEのビルド番号とOSの組み合わせが同じでもHTMLと認識される環境とXMLツリーが表示される環境があります。
ファイルの中身を見てくれるお陰で、拡張子やContent-Typeが誤っている画像ファイル等をうまく表現出来たりするのですが、その所為で正しい記述を勘違いするのは大き過ぎる代償。
ファイルタイプ決定のプロセスに、付け加えると、
かな。
http://とfile://を似た様な物とし過ぎているのがいけません。
Re:Online Solutions 社によると (スコア:0)
つうか、同じ扱いじゃないですか?
Re:Online Solutions 社によると (スコア:1)
とか。
飽くまで、ローカルのファイルシステムを用いて、ローカルな環境の流儀に則ってブラウズする為の物で、その点はIEも外していないと思います(嫌な流儀かもしれないけど)。
こう書いたら、IEは、fileスキーマを拡張してhttpスキーマを実装している様にも思えるなあ……。