mod_cacheでキャッシュされずに悩んだ話
一部コンテンツがmod_cacheにキャッシュされずに悩んだのが解決したのでメモ。
ググるとだいたいExpiresを設定するように書かれていて大体はこれで解決したけど、さくらのレンタルサーバで動かしているwordpressのfeedがどうしてもキャッシュされない。
まず、mod_cacheの動作状況を調べるため、httpd.conのLogLevelをdebugにしてエラーログを眺めてみる。
すると、以下の様なメッセージが見つかった。
[debug] mod_cache.c(141): not use cache
これで実際にキャッシュが利用されていないことが確認できた。
続いて以下のようなメッセージが見つかった。
[debug] mod_cache.c(583): cache: /blog/feed/ not cached. Reason: Cache-Control: no-store present
これで原因が分かった。
さくらレンタルサーバでお手軽にwordpressをセットアップしたので、ヘッダにno-storeを設定したわけではない。
これを解決するにはphp.iniに以下を追加する。
session.cache_limiter = public
これで解決。
WordPressでパーマリンクを変更しようとしてハマった話
仕事でWordPressを利用したblogの構築を行った時の話。
サーバはさくらのレンタルサーバを利用することで、WordPressのインストールを省略。
DocumentRoot以下にwpディレクトリが作成され、簡単に利用出来るようになった。
既存サイトへのblogの追加のため、リバースプロキシの設定で「/blog」へのリクエストをさくらレンタルサーバの「/wp」へ飛ばし、WordPressの「サイトアドレス」の設定を「http://xxx/blog」にすることで問題なく準備が整った。
ここまでは良かったが、リリース前にURLの形式が「?p=xxx」だとSEO的にどーなのよということになりパーマリンクの変更を行ったところ、全てのページが「ページが見つかりません」という状態に。
ググると、トップページは見えるけど記事が見えなくなるとかそもそも404になるとか、そんな状況はあるみたいで、その対処を行っても改善されず。
一日悩んで、「WordPressアドレス」と「サイトアドレス」が異なることを思い出し、ドキュメントルートにblogという名前でwpへのシンボリックリンクを作成し「WordPressアドレス」を「http://xxx/blog」へ変更したところ、問題なくページが閲覧できるようになった。
heapに2g以上食わせた場合のjmap
jmapの-Jオプションで-d64を渡さないとダメらしい。
jmap -J-d64 -heap pid
http://www.syboos.jp/opensource/bookmark/detail/20080828165337963.html
これで出力されるファイルのサイズがheapで指定したサイズになった。
PHPでURLエンコードされた文字列をJavaでURLデコード出来なかった話
PHPで実装された外部の決済システムとの連携を行っている。
サイトリニューアルに伴いテンプレートを修正しているのだけど、新たに検索ボックスを追加することになった。
テンプレートはShift_JISと決められているので、Java側ではShift_JISでエンコードされた文字が渡されると思い、
String decoded = URLDecoder.decode(keyword, "Shift_JIS");
のようなコードを書いたのだけど、どうもデコード出来ない。
検索ボックスに入力した「フルーツ」という文字が、「%83t%83%8B%81%5B%83c」とエンコードされている。ならJavaならどうエンコードされるのかと思って調べると「%83%74%83%8B%81%5B%83%63」となる。
どうやらphpのencodeurl関数だとこんなエンコードをするらしい。
しょうがないのでcommonのURLCodecのお世話になって解決。
Strutsのセッションが維持できなかった原因
まだまだ元気にStruts1.1で開発してます。
今月からサイトリニューアルを行っていて、ローカルでisTokenValidでコケることが度々あった。
本番だと特に問題ないので気にしていなかったが、ちょっと原因を調べてみた。
ローカルの環境としては、apache<->tomcatで連携している。
tomcatのコンテキストは「/xxx」なのだけど、apacheで「/」->「/xxx」に変換して表からは「/」でも「/xxx」でもアクセス出来るようにしている。
で、セッションが維持出来ないのはこの構成が原因だった。
「/」でアクセスするのは最初だけでlinkタグが出力するのは「/xxx」になるのでセッションが維持できていたのだが、新しく作ったajaxでアクセスする箇所が「/do/yyy」とベタで書いていたため、tomcatがコンテキストが変わったとみなしてセッションを新しくしていたというオチでした。