#バイナリファイルもだけど、アプリが使っているdbなんかも結局同じ。
#dbに運用中のデータが含まれるなら、バージョン管理というよりバックアップ管理に近くなりそうだけど、境界は曖昧なのかな。
#ORマッパとか持っているとDBの構造がコードとは不可分になるので。
#データというよりは構造の方の変化が関係あると思う。
#いちおうの切り分けとしては、スキーマは「ソース」の方に所属するってことなんじゃないかと。
#ただ、ソースとデータがいつでも綺麗にわけられるとは限らない、ってのは確かだけど。
#そう思います。
#HTTPに関して教えて欲しいんですが、
#webブラウザからのリクエストヘッダを見ていて、
#Pragma: no-cacheってのが付いてくる場合と付いてこない場合があるんですが、
#一般的にブラウザがこれを付けたり付けなかったりするのはどういう判断にもとづいているんでしょう？
#ちなみにIEだとPragma: no-cacheですが、
#Chromeで見るとCache-Control: no-cacheで、
#基本的な意図は同じだと思うんですが、
#付いたり付かなかったりのパターンはどっちのブラウザでも同じ。
#少し具体的に言うと、
#フォーム認証後にサーバからAというページが返ってきますが、
#(302からリダイレクトして返ってくるページで)こいつのGETはno-cache
#このページにはframeが含まれてて、こいつのsrcのGETはno-cache-なし。
#私もcache回りの理解は怪しいんですが(特にproxyが絡んだ時
#認証については、「ページAをGET→認証フォーム→POST→302で再びページAをGET」というパターンだとすると、
#中間で誰かが最初のページAへのリクエストのレスポンスをキャッシュしてて、二度目のページAへのリクエストにそれを返しちゃったらまずいですよね。キャッシュされてるのは認証フォームですから。
#最初のページAへのGETから302で認証フォームへリダイレクトされる場合にはこれはあてはまらないかもしれないけど。
#そうなんです。まさにそのケースっぽいんです。
#javascriptが埋めてあって、location.reload()をさせると今度はno-cacheが付いてリクエストされるんですよね。
#これはググってたら、情報があって、F5とかlocation.reload()はno-cacheなリクエストヘッダを付けるっぽい。
#認証までの間はno-cacheが付くのに、それ以降のページはno-cacheが付いてないっぽいので、どういう判断なんだろう？と。
#フォーム認証なんて別にブラウザにとっては何か意味のあるものではないですよね？
#302レスポンスのキャッシュについてはrfc2616の13.4に言及があった。デフォルトではキャッシュしちゃいけないけど、クライアントがキャッシュを明示的に許しててその範囲に入ってればキャッシュされる可能性がある。とすると認証によって状態が変わった後にはno-cacheで確実に取り直すのがいいって判断かな。
#つまり、ユーザアカウントとパスワードを入力してOKをもらったという現象とカートに商品をつっこんだという現象とは区別できないと思ってるんだけど。
#確かに、フォーム認証自体は認証でないPOSTと区別がつかない。認証後にはPOST->302->GETのパターンでno-cacheはつかないの?
#いえ、ついているんです。
#それならそのパターンを認識してno-cacheつけてるんじゃない? 安全側に倒してってことで。
#ああ、そうか、最初のはそうですね。
#というかカートに商品を突っ込んでたら表示が変わってる可能性もあるから、一度POSTしたらその直後はno-cacheで取り直すっていうのが認証にかかわらず安全だってことかなあ。
#そうなってますね。
#確かに。そこはPOSTは副作用があるものだからという理解でよさそう。
#F5やlocation.reload()は「最新の情報でリフレッシュしたい」って意図だろうからno-cacheはもっともだと思うし。
#うん。そうですね。
#とするとframeに含まれているページの取得時にno-cacheなのはそういう流れにのってないからか。
#基本的にはno-cacheしたくない。
#としてあって、reloadとかPOST後などで302リダイレクトをくらう場合にはno-cacheという判断か。
#あ、まちがえた。
#「frameに含まれるページの取得はno-cacheが付かない」だった。
#付かないのは単なるGETだからか。
#デフォルトはno-cacheを付けずにパフォーマンスを上げるんだけど、reloadとか302の場合はno-cacheで強制的にサーバから再取得と。
#あぁなんかこれまでのアクセスログの辻褄が完全に該ったかも。
#すでにframeとか見なくなって久しいけど、これもいやだなぁ。
#ありがとうございました。
#Flash 屋さんの感覚だと、「クライアントのキャッシュ制御は信用するな」というのが定説だったので、GET の時に URL の後ろにダミーのパラメタをつけてリクエストするのが定石になってました。
#私はサーバ側を書いててキャッシュではまることが多いですね。サーバでon the flyで生成したデータをダウンロードさせる時とか。no-cache見てくれない(ように思える)時もあってダミーパラメータつきのurlにリダイレクトさせたりとかいろいろ。
#jqueryも似たようなもんか。
uncache=....ってクエリパラメータ付けてnew Dateとか使ってキャッシュを避けてたりする。
やっぱりこれはクライアントのキャッシュ対策でプロキシを意識してはいなかったけど。
#RESTfulに作っておけばほぼ問題無いはずだけど、古いアーキテクチャとかでサーバーサイドでセッションオブジェクトをバリバリ使ってて、その状態によってレスポンスボディが違うとかは怖いな。
Gauche > Archives > 2011/06/06