Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
んで、Content-Type無視は (スコア:2, 参考になる)
IEの不思議 [bitarts.jp]
こーゆーのを、まず何とかして欲しい。
Re:んで、Content-Type無視は (スコア:0)
リンク先の例でimage/gifを送られちゃうと正しく表示できないのは一緒だし。
不適切なContent-Typeを送るサーバがあっても基本的にクライアント側では何もできないのだから、ユーザの指示で明示的にContent-Typeを上書きできるUIを用意して欲しい。
Re:んで、Content-Type無視は (スコア:0)
「正しく表示できない」って何? image/gifだと言ってるのに壊れているのだから表示できないのが「正しい」わけですが。
image/gifを送ってるのに勝手にhtmlとみなしてタグを解釈されたりする方がよっぽど超迷惑。
Re:んで、Content-Type無視は (スコア:0)
何を基準に「正しい」と言ってるの？
# odコマンドみたいに16進ダンプを表示するアプリは「正しくない」のかなぁ？
Re:んで、Content-Type無視は (スコア:1)
以下はテケトーな拙訳。
Re:んで、Content-Type無視は (スコア:0)
以下のツリーだから、IEの動作は関係ないですね。
Content-Typeが与えられて、そしてそれが間違っていた場合に、 テキスト表示や16進ダンプのような代替方法で ユーザにファイル内容を明かしてはいけない(MUST NOT) ことの根拠を聞いているのだけど？
Re:んで、Content-Type無視は (スコア:1)
禁止(MUST NOT)されてはいませんが…熟慮の末にそういう実装にはしなかったんではないですかね？
考えられる理由その1：単純に実装が面倒くさい
「ヘッダが間違ってる」と判断する基準を考えるだけでげんなりしますし、そんなコード書いてたらブラウザが肥大化してしまいます。
考えられる理由その2：実装して正しく動いたって傍迷惑。
「そんなおせっかい機能があったらポップアップ広告の代用品として便利に使われそうだ」程度の予測は、私の貧困な想像力でも簡単にできます。