FireFoxの強制同期

request-browser-resident-httpを利用されてますか？　更新されないと思われているのが起動用start.curlファイルですか？それともパッケージファイルやその他のリソースですか？　ご存知かと思いますが、resync-as-ofの設定は起動ファイル自身に効かないと思います。なお、この現象はWindows上で起きてますか？

IEだと意図した挙動になるのですか？

通信の間にプロキシは挟んでいませんか？

heavybugtruckerさんも仰ってますが、ファイルの構成がしりたいです。
（パッケージなのか、起動ファイルなのか…）

heavybugtrackerさん、kinoさん

回答ありがとうございます。情報足りておらずすみません。

・request-browser-resident-httpですが、利用しておりません。
・更新されないファイルは、その画面にアクセスした際にimportされるファイルです。（ダイナミックロード利用）
　また、resync-as-ofはstart.curlに設定してます。
・Windows環境です。
・IEでは意図した通りに動いてます。
・プロキシは通していません。

通常おきない現象だと思うのですが・・Curl以外の問題がからんでいるのでしょうか・・？
こちらでももっと詳しく調査してみます。

この現象なら、サーバのクライアントのシステムクロックのズレがありそうですね、断言できませんが。

importならfirefoxのキャッシュクリアで直るの不思議な気がしますね。

ちなみにFirefoxのキャッシュ更新頻度設定は
browser.cache.check_doc_frequencyの値です。about:configで見れます。
0 = セッション毎
1 = ページにアクセスする毎に
2 = しない
3 = キャッシュしたページが古いとき (デフォルト)

request-browser-resident-httpを利用してないなら、ashimoさんが言う通りに、基本的にFirefoxのキャッシュと関係ないはずですが、不思議に思います。


RTEの再起動だけでも、更新されないですか？

(10-19-2011, 01:18 PM)ashimo Wrote: importならfirefoxのキャッシュクリアで直るの不思議な気がしますね。

ちなみにFirefoxのキャッシュ更新頻度設定は
browser.cache.check_doc_frequencyの値です。about:configで見れます。
0 = セッション毎
1 = ページにアクセスする毎に
2 = しない
3 = キャッシュしたページが古いとき (デフォルト)

私は、この種の問題が発生したとき、パケットキャプチャ（fiddler）を使ってますよ。
クライアントが発しているリクエストの種類や
Ｗｅｂサーバが返却するＨＴＴＰステータスコードを確認できますので有効ですよ。

みなさま、ありがとうございます。

実は私が直面したわけではなく、又聞き状態なので申し訳ないですが・・・・
どうやら　start.curlを直接たたいてブラウザを立ち上げているわけではなく、
OracleのBIEEというポータル（？）のようなシステムからリンクでstart.curlをたたいているようです。
（現在詳しい人間が席を外しているので明確にご説明できなくて申し訳ありません）

Oracleのシステムがブラウザに対してなにか設定していたとして、
それがCurlまで影響しているということは考えられますか？

そのブラウザがFirefoxなら、CurlがWindows上で稼働する限りはFirefoxの設定に影響されることは考えにくいですね。

(10-19-2011, 02:09 PM)okm Wrote: みなさま、ありがとうございます。

実は私が直面したわけではなく、又聞き状態なので申し訳ないですが・・・・
どうやら　start.curlを直接たたいてブラウザを立ち上げているわけではなく、
OracleのBIEEというポータル（？）のようなシステムからリンクでstart.curlをたたいているようです。
（現在詳しい人間が席を外しているので明確にご説明できなくて申し訳ありません）

Oracleのシステムがブラウザに対してなにか設定していたとして、
それがCurlまで影響しているということは考えられますか？

みなさま、すみません。

やはりIEでも同じ現象になるようです。
（同期できる人とできない人がいるようです）
※IEはOracleのシステムを経由したりしておらず、start.curlをたたいてブラウザを起動しています。

RTEを再起動しても同期されず、やはりブラウザのキャッシュ削除＋Curlのキャッシュ削除で解決されました。


必ず同期させる一番確実な方法はなんでしょうか？

インターネットオプションの全般タブ「閲覧の履歴」の設定が「確認しない」などになっていると
CurlがIEキャッシュから古いパッケージファイルを読み出してしまう可能性ありますね。

Curlの同期機能を正確に動作させる条件に満たせているなら、rsync-as-of 未来日付で、確実に更新される仕組みになっていると思います。またこのようにrsync-as-of を利用する場合、ブラウザの設定に影響されません。

Quote:>やはりブラウザのキャッシュ削除＋Curlのキャッシュ削除で解決されました。

okmさんのこの情報によると、パッケージキャッシュがサーバ側のコンテンツより古くないと判断されているので、システムクロックのクラサバ間の違いがあることが今のところ一番の可能性かと思われます。


ただ、徹底的に解決するにはまだ詳しく調査が必要と思います。調査の手掛かりとしては、Curlの開発ドキュメントに載っている同期機能に影響する要素を確認し、関係しそうなところから調査しないと確実な原因は判明できませんね。
この辺の調査は大変だと思いますけど...

(10-19-2011, 04:00 PM)ashimo Wrote: インターネットオプションの全般タブ「閲覧の履歴」の設定が「確認しない」などになっていると
CurlがIEキャッシュから古いパッケージファイルを読み出してしまう可能性ありますね。

おはようございます。

みなさん回答ありがとうございます。
インターネットオプションは確認しましたが、「自動的に確認する」になっていました。

クライアント端末の時間がズレていたとも考えられません・・。
Curlの同期機能を正確に動作させる条件を再度確認してみます・・。

(10-19-2011, 06:39 PM)heavybugtracker Wrote: Curlの同期機能を正確に動作させる条件に満たせているなら、rsync-as-of 未来日付で、確実に更新される仕組みになっていると思います。またこのようにrsync-as-of を利用する場合、ブラウザの設定に影響されません。

Quote:>やはりブラウザのキャッシュ削除＋Curlのキャッシュ削除で解決されました。

okmさんのこの情報によると、パッケージキャッシュがサーバ側のコンテンツより古くないと判断されているので、システムクロックのクラサバ間の違いがあることが今のところ一番の可能性かと思われます。


ただ、徹底的に解決するにはまだ詳しく調査が必要と思います。調査の手掛かりとしては、Curlの開発ドキュメントに載っている同期機能に影響する要素を確認し、関係しそうなところから調査しないと確実な原因は判明できませんね。
この辺の調査は大変だと思いますけど...

(10-19-2011, 04:00 PM)ashimo Wrote: インターネットオプションの全般タブ「閲覧の履歴」の設定が「確認しない」などになっていると
CurlがIEキャッシュから古いパッケージファイルを読み出してしまう可能性ありますね。

原因がわかりました。

同期機能を正確に動作させる条件にあってない項目がございました。

みなさま、親身にご相談に乗っていただき、ありがとうございました！

HTTPサーバのログを見ると、ファイルをGETしにいってるのですが、リターンコード304で更新されていないと認識していました。
詳しくきいてみると、
今回サーバへリリースしたファイルですが、以前サーバにのっていたものより古い日付のものをリリースしたようです。

ということで、タイムスタンプを過去にしてしまったためにおきた問題でした。

Curlのドキュメントにも書いてあったのですが、こちらの確認ミスです＞＜
大変お騒がせいたしました。