新生鳩丸掲示板♯

>　まあその辺の話も一応分かってはいるのですが、現状で単純に Content-Type: application/xhtml+xml を吐いても読めなくなるだけのような気がするのですよね。

IEあたりは後方互換性の問題とかで【謎】絶対撤回してくれなかったりしますから【謎】いっそ読めなくなってもらったほうがありがたいという考えなのだと思います【謎】。現状ではかなり過激っぽいですが【謎】。

XHTML 1.1はapplication/xhtml+xmlで流せということはすでに旧来のHTML UAとの互換性は考えていないわけで、そういうものをtext/htmlで流されると既存のUAが消化不良を起こすからかえって迷惑という発想もありえます【謎】。

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

ていうかそこまでしてXHTML 1.1使うメリットって何でしたっけ【謎】。やはりrubyですか【謎】。

>>会員じゃないのでできるのか否かはわかりませんが(謎)、出力時にサニタイズすればいいのに。

>　というか、6/20 に行われた「緊急対処」は、無差別に出力時にサニタイズしてタグを全て無効化するという対処でした。なのでそれは可能どころか実際に行われていたわけです。

>　一生このままで良かったのではないかと思うのですか、7/3 に何故か入力時に特定タグだけ消す処理が入りました。これは以前もあったようですが、ルーチンが変わって style 属性なども弾くようになりました。

>

>　で、ここで出力時のサニタイズを無効にするつもりだったのでしょうが、何らかの事情でそれは出来なくて、現状は入力時と出力時の両方にサニタイズが行われるという状態になっています。しかも入力時サニタイズはタグをエスケープするのではなくて削除しているので、現状ではタグが一切使えない上に HTML の話題に支障が出るという、ものすごい状態になっています。

>

>　つくづく意味が分かりませんが、まあともかくそんな感じです。

不用意に消去フィルタを入れて他のフィルタと適用の順番を間違えたりすると凄いことになるとスターダストさん【誰】とかが言ってた気がしますが本当に大丈夫でしょうかね【謎】。

スターダストさんといえば【謎】図書券をくれるというのでメーってみたらその後なしのつぶてなのですが、もしかして見事にソーシャルハクられましたか【謎】。

>　つくづく意味が分かりませんが、まあともかくそんな感じです。

意味がわかりませんが、状況などはわかりました。なんというか、御愁傷様です(謎)。＞誰となく

記事投稿完了時の投稿時刻っぽいもののタイムゾーンが JST ではないみたいです。JST っぽい表記なのに(謎)。

分かっているであろうということは分かっているのですが(謎)、まあ、あの、その(謎)。

>　もちろん、Accept: の中に application/xhtml+xml があったらapplication/xhtml+xml で返してやって問題ないのだろうと思いますが、それにしても実装が面倒な割にほとんど意味がないような気がしていまして……。

御意。

>会員じゃないのでできるのか否かはわかりませんが(謎)、出力時にサニタイズすればいいのに。

　というか、6/20 に行われた「緊急対処」は、無差別に出力時にサニタイズしてタグを全て無効化するという対処でした。なのでそれは可能どころか実際に行われていたわけです。

　一生このままで良かったのではないかと思うのですか、7/3 に何故か入力時に特定タグだけ消す処理が入りました。これは以前もあったようですが、ルーチンが変わって style 属性なども弾くようになりました。

　で、ここで出力時のサニタイズを無効にするつもりだったのでしょうが、何らかの事情でそれは出来なくて、現状は入力時と出力時の両方にサニタイズが行われるという状態になっています。しかも入力時サニタイズはタグをエスケープするのではなくて削除しているので、現状ではタグが一切使えない上に HTML の話題に支障が出るという、ものすごい状態になっています。

　つくづく意味が分かりませんが、まあともかくそんな感じです。

>http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020430/xhtml-media-types.html あたりの Note のことじゃないでしょうか。

　まあその辺の話も一応分かってはいるのですが、現状で単純に Content-Type: application/xhtml+xml を吐いても読めなくなるだけのような気がするのですよね。

　もちろん、Accept: の中に application/xhtml+xml があったらapplication/xhtml+xml で返してやって問題ないのだろうと思いますが、それにしても実装が面倒な割にほとんど意味がないような気がしていまして……。

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020430/xhtml-media-types.html あたりの Note のことじゃないでしょうか。Note ですし(謎)まったくこだわりませんが(謎)。

会員じゃないのでできるのか否かはわかりませんが(謎)、出力時にサニタイズすればいいのに。

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

　"typographic error" すなわち「誤植」の略です。

　用語集に入れておきましょうか。

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

　うーむ、実はリファレンスを先に作ろうかと思っていたりしたのですが。

　こっちのプライオリティ上げようかしら。

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

　サイトはこの辺りに。

http://satsuki.sakura.ne.jp/~rockman/

>>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 と注意書きがある勢いですからキャッシュされると思いますが、これはそもそも使っていないので問題ないです。