新生鳩丸掲示板♯

>>typeというより、

>

>typoのtypoですか【謎】。

あっ(^^;

ところで、

typoってtypeを打ち間違えたのが語源ってわけでもないのですか。

ロックマン【何】が大好きです。

それはさておき【謎】それはそれで【謎】楽しみにしております。

それはそうと【謎】以前鳩丸板【何処】で視覚が不自由でもとかいう【謎】アクセシビリティ絡み【謎】でロックマンさん【ハンドル】という方がいらしたな【謎】。

>HttpCacheability.Serverではどうですか。

　見事に

Cache-Control: no-cache

Pragma: no-cache

Expires: -1

　が送出されました。HttpCacheability.NoCache でも同じです。

　両者の違いは、たぶん ASP.NET のキャッシュ機能が使われるかどうかなのではないかと思います。想像ですが。

>あるいは拡張ヘッダを書き込む機能でLast-Modifiedを追加するとLast-Modifiedと認識されなくて何とかなるとか。

　やー、もう public で良いです。

　POST の結果だけ no-cahce になるようにしておきます。

>Response.Cache.SetCacheability(null);

>

>　なんてので上書きしようとしても例外が発生して NG。無理げです。

HttpCacheability.Serverではどうですか。

MSDNの解説によるとno-cacheが付くそうですがその説明が正しいとするとServerAndNoCacheとの違いがよくわかりません。

あるいは拡張ヘッダを書き込む機能でLast-Modifiedを追加するとLast-Modifiedと認識されなくて何とかなるとか。

>しかもログイン画面を含めフォームをＳＳＬ化していないところが多いのにはびっくりです。

　どうも全体的に「成りすまし」に対する危機感は薄いみたいですね。

　フォームをポップアップウィンドウにして URL 窓を隠したり、フレームの中に入れてしまっていたりするところが結構ありますが、URL が確認できないと全く関係ない場所にそっくりなフォームを作られても見分けがつきません。

　これに限らず、Web アプリケーションのセキュリティは本当にお粗末なところが多くて頭が痛いです。

>それより【謎】301のときCache-Control: privateのままでせっかくキャッシュ可能なはずの301をキャッシュできなくなっていることを発見しました【謎】。

　あー、public にしておきます。

>ていうかpublicもprivateもno-cacheも吐かないような指示はできないのですか【ピュア】。

　どうも Last-Modified を設定すると強制的に Cache-Control がつくらしく、そのデフォルトが private のようです。で、

Response.Cache.SetCacheability(null);

　なんてので上書きしようとしても例外が発生して NG。無理げです。

言われるとおりです。

次のキーワードでGoogle検索してもまともなのはこちらだけでした。

SSL FORM ACTION HTTPS POST

しかもログイン画面を含めフォームをＳＳＬ化していないところが多いのにはびっくりです。

>　あら、POST の応答もキャッシュされちゃいます？

>　Auth については RFC2616 に See also と注意書きがある勢いですからキャッシュされると思いますが、これはそもそも使っていないので問題ないです。

|9.5 POST

(略)

| Responses to this method are not cacheable, unless the response

| includes appropriate Cache-Control or Expires header fields.

POSTの説明のほうがこうなってますからキャッシュされるのでは。302 Foundもキャッシュ可能に化けますが302が吐かれるときにはCache-Contorlは付いてないようなので問題なさげです【謎】。それより【謎】301のときCache-Control: privateのままでせっかくキャッシュ可能なはずの301をキャッシュできなくなっていることを発見しました【謎】。

ていうかpublicもprivateもno-cacheも吐かないような指示はできないのですか【ピュア】。できなかったらフィードバックよろしく【謎】むらまささん【誰】。

>Cache-Control: publicは通常キャッシュできないもの(POSTへの応答とかAuthorization付きのリクエストへの応答とか)もキャッシュしてよいという意味の指示ですが、本当に大丈夫ですか? 【謎】

　あら、POST の応答もキャッシュされちゃいます？

　Auth については RFC2616 に See also と注意書きがある勢いですからキャッシュされると思いますが、これはそもそも使っていないので問題ないです。

>　ということで、

>

>Response.Cache.SetCacheability(HttpCacheability.Public);

>

>　を追加して public にるようにしてみました。

>　なんでコイツのデフォルトが private になっているのかイマイチ分かりませんが、まあこれで解決かと。

Cache-Control: publicは通常キャッシュできないもの(POSTへの応答とかAuthorization付きのリクエストへの応答とか)もキャッシュしてよいという意味の指示ですが、本当に大丈夫ですか? 【謎】

そうですね。このログが出ても特に問題ないはずなんで、気にしなければ良いと思います。

>http://support.microsoft.com/default.aspx?scid=kb;ja;266416

　うーん、なんかあんまりやりたくない感じの作業ですね……。

　とりあえず放置の方向で。

Windows Server 2003をインストールした時もそのログが残るようになりますね。

この辺で解決できるかも。

http://support.microsoft.com/default.aspx?scid=kb;ja;266416

　ということで、

Response.Cache.SetCacheability(HttpCacheability.Public);

　を追加して public にるようにしてみました。

　なんでコイツのデフォルトが private になっているのかイマイチ分かりませんが、まあこれで解決かと。

>ところで【謎】このサイトからの応答ヘッダにCache-Control: privateが含まれてるのはどうしてですか。

　謎です。むしろ Microsoft に聞いて欲しいくらいの勢いですが、ちょっと調べてみましょう。

ところで【謎】このサイトからの応答ヘッダにCache-Control: privateが含まれてるのはどうしてですか。何か公開キャッシュに蓄積されると困るものがあるのでしょうか【ピュア】。

>>きわめて危険、だとしても、パレットを使わなければ良いのでしょ?

>　そりゃそうです。

　あー、追記の具合でそうでない風に読めるという話ですか。

　ちょっとなおして置きます。

>きわめて危険、だとしても、パレットを使わなければ良いのでしょ?

　そりゃそうです。

きわめて危険、だとしても、パレットを使わなければ良いのでしょ?

>そういえば【謎】このサイト【何処】はXHTML 1.1で公開してるのにMIMEタイプがtext/htmlなのはどうしてですか【ピュア】。

　application/xhtml+xml にしてもあんまりメリットがないような気がするので。

　Accept: をみてネゴシエーションしようかとも思ったのですが、あんまりメリットがなさそうだったので実装してなかったりします。