アカウント名:
パスワード:
たしかに不用意にFireWallに穴を開けるぐらいならという視点ではHTTPを使いまくるというのは分からないこともない。 どこかのポートを開けて独自のプロトコルを実装するより楽だしね
(件のインターネットディスクに限らない話でいえば)結局、http のうえにアプリケーション独自のプロトコルを のせて動くことになるわけだから、現行の tcp にかわって http をつかうようなもの。一層上に上がっただけで、最終的にFireWallでセキュリティ云々の問題は解
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
でもなぁ・・・ (スコア:2, 参考になる)
どこかのポートを開けて独自のプロトコルを実装するより楽だしね
でもこれだけHTTPに偏るとセキュリティホールが見つかったとき
きっついだろうな。趣は違うけどIISでさんざん見せつけられてるように
FireWallじゃ防御しきれないから
Re:でもなぁ・・・ (スコア:4, すばらしい洞察)
(件のインターネットディスクに限らない話でいえば)結局、http のうえにアプリケーション独自のプロトコルを のせて動くことになるわけだから、現行の tcp にかわって http をつかうようなもの。一層上に上がっただけで、最終的にFireWallでセキュリティ云々の問題は解
いまいち理解できていないのですが,この問題と言うの (スコア:1)
(1) HTTP そのものの問題の場合。
仕様/実現方法のどちらの場合に対しても,
HTTPを転送に使う上位プロトコルに
問題があってもなくても,もちろん問題はそのまま残る。
(2) HTTP そのものには問題がない場合。
=その上位プロトコルが問題
・その上位プロトコルをホストが処理する場合
その上位プロトコルの実現方法の問題。
または,
HTTPの仕様に起因しない問題,であれば,
その上位プロトコル自体の問題。
または,
HTTPの仕様に起因する問題,であれば,
上位プロトコルの前提の問題。
つまり,
転送がHTTPだろうがなんだろうが関係ない。
☆
・その上位プロトコルをホストが処理しない場合
(1) でない場合は,そのホストには元々関係ない。
☆で問題となった場合に,HTTPとその上位プロトコルを区別して,
遮断できないから問題,ということでよいのでしょうか?
と,言うことは,
悪くないものは区別してやる必要がないですから,
元々その上位プロトコルがやろうとしていたこと,
そのものが悪いことだ,と言うことですね!
-- LightSpeed-J