アカウント名:
パスワード:
絶望的観測で言うなら、
というところでしょうか。
私はApacheを使っていることを知っていますし混乱もして
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
○○だからor○○じゃないから安全 (スコア:2, 参考になる)
さて、ここから根拠もなく言ってきます。
よって、マイナスモデレートされるべきかもしれません。
<根拠なしの文>
きっと、CodeRedで話題になったIISじゃないから安心と思って
導入後、ずっと放置してあるApacheとかが
主な長期的なキャリアになるのでしょうね・・・
# いまだにCodeRed系も時々誘惑してるし、
# 当てない人は、いつまでたっても当てないでしょうし・・・
さて、今回のですが、
・分母の数が絶対的に多い
・脆弱性発見から、ワームが出回るまでの期間の短さ
・複数プラットフォームで、似たような脆弱性がある
Re:○○だからor○○じゃないから安全 (スコア:2, 参考になる)
絶望的観測で言うなら、
というところでしょうか。
私はApacheを使っていることを知っていますし混乱もして
Re:○○だからor○○じゃないから安全 (スコア:4, 参考になる)
>サーバの管理者は、そこまで知らないといけないのでしょうか?
知らなくてもApacheの管理者はやれますが、知ってればそれだけ
多くのことに対応できるでしょうね。ま、一般論ですが。
ちなみに「chunked転送」とは、送信時にコンテンツのサイズ(Content-Length)
を指定せずにメッセージを送信する方法です。この際Transfer-Encoding: chunkedを
ヘッダに付加します。
動的なメッセージの場合、メッセージを生成しながら転送できるので
(メッセージ全体を生成した後で転送する必要がない)、パフォーマンス面で
有利です。
クラ
chunked ennoding (スコア:1)
いて、このchunked処理にはいろいろ問題がありそうだなと
思っていたところへ、この騒ぎになりました。
ちょっと忘れられているかもしれないDelegateにも、随分こ
の処理がらみでパッチが出ていたり、処理ミスがあったよう
です。また、HTTP/1.1指定によってHTTPコネクションを複数
リクエストに渡って使用すると、途中のプロキシが対応して
いなかったり、バグがあったりで、認証がらみでぼろぼろに
なるような現象がよく出ます。
仕様を作った方が悪いのか、仕様を正しく実現できないのが悪
いのか、どっちもどっちですが、chunked encodingはバグの
山のような気がしてなりません。