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

すべてをHTTPで」記事へのコメント

  • たしかに不用意にFireWallに穴を開けるぐらいならという視点ではHTTPを使いまくるというのは分からないこともない。
    どこかのポートを開けて独自のプロトコルを実装するより楽だしね

    でもこれだけHTTPに偏るとセキュリティホールが見つかったとき
    きっついだろうな。趣は違うけどIISでさんざん見せつけられてるように
    FireWallじゃ防御しきれないから
    • たしかに不用意にFireWallに穴を開けるぐらいならという視点ではHTTPを使いまくるというのは分からないこともない。 どこかのポートを開けて独自のプロトコルを実装するより楽だしね

      (件のインターネットディスクに限らない話でいえば)結局、http のうえにアプリケーション独自のプロトコルを のせて動くことになるわけだから、現行の tcp にかわって http をつかうようなもの。一層上に上がっただけで、最終的にFireWallでセキュリティ云々の問題は解

      • 「その」プロトコルに問題がある場合,の分類。

        (1) HTTP そのものの問題の場合。

          仕様/実現方法のどちらの場合に対しても,
          HTTPを転送に使う上位プロトコルに
          問題があってもなくても,もちろん問題はそのまま残る。

        (2) HTTP そのものには問題がない場合。

          =その上位プロトコルが問題

           ・その上位プロトコルをホストが処理する場合

             その上位プロトコルの実現方法の問題。

             または,

             HTTPの仕様に起因しない問題,であれば,
             その上位プロトコル自体の問題。

             または,

             HTTPの仕様に起因する問題,であれば,
             上位プロトコルの前提の問題。

             つまり,
             転送がHTTPだろうがなんだろうが関係ない。
             ☆

           ・その上位プロトコルをホストが処理しない場合

             (1) でない場合は,そのホストには元々関係ない。

        ☆で問題となった場合に,HTTPとその上位プロトコルを区別して,
        遮断できないから問題,ということでよいのでしょうか?

        と,言うことは,
        悪くないものは区別してやる必要がないですから,
        元々その上位プロトコルがやろうとしていたこと,
        そのものが悪いことだ,と言うことですね!

        --
        -- LightSpeed-J
        親コメント

物事のやり方は一つではない -- Perlな人

処理中...