電気ウナギ的○○でタグ「CGI」が付けられているもの

InternetExplorer での挙動なのだが、

1.CGI 経由で出力された FORM 入力画面を表示
2.値を入力して Submit
3.確認画面の表示
4.ブラウザの戻るボタンで前画面に戻る
5.FORM に入力していた値はそのまま保持されている

というのが、まあ、普通の動きだよな。

<input type="button" value="入力ページに戻る" onClick="history.go(-1)">
とか、JavaScriptで前ページに戻る場合も一緒ね。

で、この 3 と 4 の処理の間に、別のページを別タブや別ウィンドウで開いちゃうと、なんとキャッシュがクリアされて 5 の「FORM に入力していた値はそのまま保持されている」が「FORM がリセットされ何も入力されていない状態になる」のだ。

これは、InternetExplorer でだけ発生する問題で、Firefox 等では発生しない。

完全に InternetExplorer のバグだよな。他のタブやウィンドウでWebページを開いたとかどうとか、そういうことがキャッシュの保持に影響しちゃあいかんじゃろう。
別タブとか別ウィンドウでページを開いてる意味がないじゃん。

システム的に考えて、これはバグ以外の何者でもない。:-P

しかし、Microsoft やその信者達は、これは仕様と言い張るのである。馬鹿どもが。

で、この問題は、のほほんのほほんさんが「生涯一マークアップエンジニアだっ!!」というブログで書かれているように、取りあえずは出力する HTML に、

<meta content="86400" http-equiv="Expires"/>

という「明示的にキャッシュを残すようにする」meta ダグを加えてやれば解決する。

俺がわざわざ挙動の説明で「CGI 経由で出力された FORM 入力画面」と書いているのには意味があって、実は、(Apache でしか実験していないが)固定コンテンツの FORM 入力画面ではこのような問題は発生しない。
CGI や PHP で出力した画面で良く発生するのだ。

多分、HTTP ヘッダの違いによる挙動の違いなんだと思うんだな。

ということで、固定コンテンツと CGI の出力の場合でヘッダを比べてみると、

<CGI から出力したコンテンツの場合>
HTTP/1.1 200 OK
Date: Mon, 23 Aug 2010 01:08:16 GMT
Server: Apache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8


<固定コンテンツの場合>
HTTP/1.1 200 OK
Date: Mon, 23 Aug 2010 01:08:52 GMT
Server: Apache
Last-Modified: Thu, 29 Jul 2010 03:53:09 GMT
Etag: "14939d-1d5b-48c7eac295340"
Accept-Ranges: bytes
Content-Length: 7515
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

むむむ?何か、それっぽい違いはねえなあ。(^^;
固定コンテンツの場合は Cache-Control ヘッダが飛んでるのかと思ったけど、そういうわけでもないような・・・

また分かんなくなっちゃった。

今回、俺は時間がなくてテスト出来なかったんだけど、CGI/PHP 経由で出力した画面の FORM の内容がクリアされてしまうという現象に遭った人は、HTML を吐く時に、

print "Content-type: text/html;charset=UTF-8\n\n";

ってしているところで、

print "Content-type: text/html;charset=UTF-8\n";
print "Cache-Control: max-age=163512\n";
print "Expires: Tue, 24 Aug 2010 22:34:03 GMT\n\n";

とか変えてみて、キャッシュのクリアがおこなわれてしまうか試してみてちょうだい。
(Tue, 24 Aug 2010 22:34:03 のところは、現在時刻に変更してね)

では、結果を待つ。(俺も機会があれば試してみるので。わざわざやるのは面倒くせえ(^^;)

ま、何にせよ、InternetExplorer がこんな糞みたいな(本当はバグの)仕様のせいで、こんなに苦労しないといけないんだけどな。

阿呆だった。
誰がだ?俺がだ。

俺は駄目なヤツだ。
駄目なヤツは俺だ。

ああ、何ということだ。何ということだ。

こんな、あんな、そんな・・・ああ・・・

俺の4時間を返せぇ~

いや、何かというと、CentOS 上の Perl5.8 で PostgreSQL を DBD::Pg モジュール経由で使う設定をしたのだが、シェル上ではそのプログラムを実行出来るのに、Apache の CGI として実行すると駄目というケースが発生したのだ。

install_driver(Pg) failed: Can't load '/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/Pg/Pg.so' for module DBD::Pg: libpq.so.5: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
 at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
Perhaps a required shared library or dll isn't installed where expected
 at ./test.cgi line 89

こんなヤツね。

root や postgres ユーザでシェル上で実行すれば正常に動くのに・・・
これの解決に(このことばかりやってたわけではないが)4時間もかかってしまい、こんな時間になっているわけである。とほほ。

「それは、Apache の httpd.conf に SetEnv LD_LIBRARY_PATH /usr/local/pgsql/lib って書けばいいのだよ!」とか言う?
確かに昔はそんなこともしてたけどなあ。
ちゃんと /usr/local/pgsql/lib も ldconfig で認識させているから問題ないのだよ。そんな問題ではないのだ。

ま、とは言いつつ、藁をもすがる気持ちで実は SetEnv もしてみたけどな。(^^;
もちろん意味はない。

結局、原因は単純だった。

/usr/local/pgsql のパーミッションが 0700 になっていただけ・・・(^^;
なので、root や、このディレクトリのオーナーである postgres だけしか(いくらちゃんとライブラリのパスを通していても)DBD::Pg モジュールが利用できなかったのだな・・・とほほ。

いつもなら、PostgreSQL をインストールするとき、あらかじめ root で mkdir /usr/local/pgsql して、インストール後に chown -R postgres /usr/local/pgsql とかするのよ。
そしたら、/usr/local/pgsql のパーミッションは 0755 で作成されるので問題なかったんだよ。

今回は、急ぎテスト環境を作りたかったので、postgres ユーザを作る時に、

useradd -g postgres -u 128 -c 'POSTGRES Admin' -d /usr/local/pgsql -m -s /bin/csh postgres

と、ホームディレクトリとして /usr/local/pgsql を作っちゃったのよ。これが不味かった。パーミッションが 0700 で作られてしまうからな。

・・・そうなんだよな。以前も別のエントリで書いたけど、俺は「BSD の人」なので、未だに Linux 系でホームディレクトリが 0700 で作られちゃうことに馴れてないのであります。(^^;

まったく。困った話だ。

結局、chmod 755 /usr/local/pgsql したら全て解決。

ググってみたら、けっこう同じような状況ではまっている人も多いので、恥をさらしてエントリを公開しておくのだ。

ああ、俺の貴重な睡眠時間が・・・

タグ

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら