パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

IE7に関する追加情報が明らかに」記事へのコメント

  • by Anonymous Coward
    どうなるのかな?

    IEの不思議 [bitarts.jp]

    こーゆーのを、まず何とかして欲しい。
    • でもサーバのContent-Typeを盲信するMozillaの挙動も迷惑。
      リンク先の例でimage/gifを送られちゃうと正しく表示できないのは一緒だし。
      不適切なContent-Typeを送るサーバがあっても基本的にクライアント側では何もできないのだから、ユーザの指示で明示的にContent-Typeを上書きできるUIを用意して欲しい。
      • > リンク先の例でimage/gifを送られちゃうと正しく表示できないのは一緒だし。
        「正しく表示できない」って何? image/gifだと言ってるのに壊れているのだから表示できないのが「正しい」わけですが。
        image/gifを送ってるのに勝手にhtmlとみなしてタグを解釈されたりする方がよっぽど超迷惑。
        • > image/gifだと言ってるのに壊れているのだから表示できないのが「正しい」
          何を基準に「正しい」と言ってるの?
          # odコマンドみたいに16進ダンプを表示するアプリは「正しくない」のかなぁ?
          • HTTP version 1.1の規格書(RFC2616)から抜粋。

            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".

            以下はテケトーな拙訳。
            entity-bodyを含むあらゆるHTTP/1.1メッセージは、entity-bodyのメディアタイプを定義するContent-Typeヘッダフィールドを含むべきである。Content-Typeフィールドが与えられない場合に限り、受信者は、その内容やリソースを同定するために使われているURIの名前拡張子を調査することによってメディアタイプを推定しても良い。もしメディアタイプが不明のままならば、受信者は"application/octet-stream"タイプとして扱うべきである。

            まとめるとこういうことです。

            1. 応答ヘッダにContent-typeフィールドがあったら、最優先でそれをentity-bodyのメディアタイプとする。
            2. Content-typeフィールドが無ければ、URIやentity-bodyの内容からメディアタイプを推測する。しなくてもいい。
            3. メディアタイプがわからずじまいなら"application/octet-stream"タイプとして処理する。

            WinXP SP1までのIEの挙動は最初の段階からいきなり違いますよね。
            親コメント
            • > Mozillaの挙動も迷惑。
              以下のツリーだから、IEの動作は関係ないですね。
              Content-Typeが与えられて、そしてそれが間違っていた場合に、 テキスト表示や16進ダンプのような代替方法で ユーザにファイル内容を明かしてはいけない(MUST NOT) ことの根拠を聞いているのだけど?
              • > Content-Typeが与えられて、そしてそれが間違っていた場合、テキスト表示や16進ダンプのような代替方法でユーザにファイル内容を明かしてはいけない(MUST NOT) ことの根拠を聞いているのだけど?
                禁止(MUST NOT)されてはいませんが…熟慮の末にそういう実装にはしなかったんではないですかね?

                考えられる理由その1:単純に実装が面倒くさい
                「ヘッダが間違ってる」と判断する基準を考えるだけでげんなりしますし、そんなコード書いてたらブラウザが肥大化してしまいます。

                考えられる理由その2:実装して正しく動いたって傍迷惑。
                「そんなおせっかい機能があったらポップアップ広告の代用品として便利に使われそうだ」程度の予測は、私の貧困な想像力でも簡単にできます。

                1. Webページを開く
                2. インラインイメージで画像を埋め込んである
                3. 画像じゃなくて実はテキストファイルで「肩こりにはレッドインテバンをどうぞ」「胃にはカンタスファインがよく効きます」。
                4. 当然画像としてロードできない
                5. ブラウザはヘッダが間違っていると判断
                6. 「正しく画像を読めなかった。内容はこうだ」というダイアログが現れ、ウザい広告文が表示される。
                親コメント
              • >ことの根拠を聞いているのだけど?

                誰が?誰に?
                普段、何か人に見えないものが見えたりして困る事はありませんか?
                疲れているのでしょう。まずは精神病院へどうぞ。

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...