08/06/24 05:38:53
送り側 ※ 実際の送信されるリクエストヘッダ
IE 6 なし (なにも無し)
IE 6 あり application/x-www-form-urlencoded
IE 7 なし (なにも無し)
IE 7 あり application/x-www-form-urlencoded
FF 1.5 なし application/xml
FF 1.5 あり application/x-www-form-urlencoded
FF 2.0 なし application/xml
FF 2.0 あり application/x-www-form-urlencoded
FF 3.0 なし application/xml; charset=UTF-8 ※1
FF 3.0 あり application/x-www-form-urlencoded; charset=UTF-8 ※1
(※. setRequestHeader('...')の有無)
(※1.表示しているカレントページのcharsetに関わらず、UTF-8で固定のようです。)
316:311
08/06/24 05:48:29
モジュール ヘッダ(#1) パース(※)
CGI::Lite なし 出来る
CGI::Lite #2 出来る
CGI::Lite #2 #8 出来ない
CGI::Lite #3 出来ない
CGI.pm なし 出来る(※)
CGI.pm #2 出来る
CGI.pm #2 #8 出来る
CGI.pm #3 出来る(※)
Apache2::Reuest なし 出来ない
Apache2::Reuest #2 出来る
Apache2::Reuest #2 #8 出来る
Apache2::Reuest #3 出来ない
php(おまけ) なし 出来ない
php #2 出来る
php #2 #8 出来る
php #3 出来ない
317:311
08/06/24 05:56:14
ずれまくりですいません。
>>315
については、一応RFCでは、フォームからの入力をPOSTする時には、必ず"application/x-www-form-urlencoded"
をヘッダに含めなくてはならないとなっております。
また、上記と似たような検証をしていたサイトがあって(といっても、そちらは1年ほど前の時点での調査でしたが)、
このようにブラウザごとに差異があるので、XHRでPOSTメソッドをリクエストをする時は、
setRequestHeader('application/x-www-form-urlencoded')が ”必須” になるとも書いてありました。
一応ここまでが、Javascript側の要因です。
>>316
Perlに関しては
#1 $ENV{'CONTENT_TYPE'}の値(ブラウザからのContent-Type リクエストヘッダ)
#2 application/x-www-form-urlencoded
#3 その他(text/plainなど)自前のLWPとHTTP::Request::Commonで、適当なリクエストヘッダをでっちあげて確認した。
#8 charset=UTF-8
※.一般的なデータ取得関数を使って、変数に値をセットできるかどうか。例:CGI::Lite->parse_form_data()、CGI.pm->Vars()、
phpだと$value=$_POST{'name'}など。CGI.pmだけは特殊で、x-www・・・以外のどんな場面であっても、
"POSTED=name=value&name=value&name・・・・"とゆう形で取得できる。
318:311
08/06/24 05:57:06
とゆうことで注目するのは、CGI::Liteだけ、"application/x-www-form-urlencoded"の後ろに"charset="が付くと、
データ取得関数でデータを取得出来ないことと、他の一般的なモジュールで本来取得できないハズの
Content-リクエストヘッダ無しの場合でも、普通にデータを取得出来てしまえるところに、混乱した原因があるようだ。
ちなみに、上の調査の追記としては、read(STDIN.$var,$ENV{'CONTENT_LENGTH}) を使えば、
全てのパターンでデータの取得が可能。(パースとデコードは全て自分でやらないといけないですが)
しかしながら、これを各moduleのデータ取得用関数の前に持ってくると、その後の取得関数が全てコケる。(値なしになる。)
また、取得関数の後に持ってきても、その前の関数の成功失敗に関わらず、データを取得できない。(phpでは未確認)
(多分STDINに対するファイルポインタが、終端まで行ってしまっためだと思う)
今までお恥ずかしいながら、ajaxに限らず、ほとんどCGI::Liteメインで書いてきた。(GET,POSTの違いも大して意識してなかった)
それにモジュールのロードが軽い(自機での測定で、CGI.pm比約四倍早い)し、自分には、CGI.pmは機能が豊富すぎて、
使いこなせてないって思ってた。
だけど、今後のこと(新しいブラウザ対応とか)を考えるに、どうもCGI::Liteだけではやっていけなくなってしまいそう。
まあ、最終リリースからもう五年もメンテされてないんで、早く乗り換えろよってのはもっともな話だとは思うけど・・。
なんかくやしいなぁ。
313さんへ、
自分はJavascriptについては、prototype.jsやjQueryなどの外部ライブラリを使ったことがなくて、余り詳しくもないんだけど、
これからはどうしようかと検討中です。でも今回の件に限れば、自分が受け側をCGI::Liteで利用したのが原因で
多分外部ライブラリ使ってても同じ現象に遭遇してたと思います。そんな時は余計に、原因の究明に困ったかも知れません。
とゆうことで、長々と失礼しました。同じような問題で悩んでる人がいたら、参考にして下さい。
319:316貼り直し
08/06/24 06:17:21
mod (#1) (※)
CL なし 出来る
CL #2 出来る
CL #2 #8 出来ない
CL #3 出来ない
Cp なし 出来る(※)
Cp #2 出来る
Cp #2 #8 出来る
Cp #3 出来る(※)
AR2 なし 出来ない
AR2 #2 出来る
AR2 #2 #8 出来る
AR2 #3 出来ない
php なし 出来ない
php #2 出来る
php #2 #8 出来る
php #3 出来ない
説明は>>317の通り。
CL=CGI::Lite、Cp=CGI.pm、AR2=Apache2::Request、php=php(おまけ)。
#2 #8 は application/x-www-form-urlencoded; charset=UTF-8 のこと。
Apache2::Requestのつづり間違えてた。
320:nobodyさん
08/06/24 10:11:34
cgiが正常ならクライアント側の問題だろ？
prototype.jsを遣わない理由がどこにある。
321:nobodyさん
08/06/24 14:59:55
RequestHeaderが違ってくるのは、XMLHttpRequestメソッドとブラウザの問題だと思うんだけど。
URLﾘﾝｸ(www.fraction.jp)
prototype.jsは関係ないんじゃない？と思ったが
XMLHttpRequestでgrepしてみると
/* Force "Connection: close" for older Mozilla browsers to work
* around a bug where XMLHttpRequest sends an incorrect
* Content-length header. See Mozilla Bugzilla #246651.
*/
こんなのが。補正してるってことかな？
RequestHeaderによっては受け取れない部分はCGI::Liteの問題。
知らないとハマるから、良い検証だったと思います。乙
322:nobodyさん
08/06/25 05:30:05
>>320さん >>321さん
318です。仰るとおり、送って来るReuestHeaderが異なるのは、各ブラウザ側の挙動の違いの問題です。
その後、教えて頂いたprototype.jsのXHR周りの動作について、手持ちのブラウザで基本的な動作確認をしましたが、
やはり送ってくるRequestHeaderはブラウザごとに違います。設定によりいくらかのヘッダの操作も出来ますが、
FireFox3で、当該の"chaesrt=..."の部分を消すことは出来ないようです。
( これもブラウザにより異なります。IEでもデフォで、"charset="が付いてきたりします。
ここら辺の違いを吸収してくれるハズのライブラリで、ブラウザごとに分かち書きとかしないといけないのは、
本末転倒のような気がします。まあJavascriptのことはスレ違いになるんで、言及はここら辺でやめときます。)
323:322
08/06/25 05:30:57
で、何が問題かと言うと、実は今自分の運営しているサイトで、CGI::Liteで書いた既存のcgiが動いてるんですが、
現在、日中平均で30req/s前後、ピーク時で90-100req/s程度のリクエストがあります。このスクリプトを導入した際に、
CGI.pmとCGI::Liteでそれぞれベンチを取ったのですが、本番環境と同一ハード,ソフトの環境で、
CGI.pmだと40rq/s位で限界、CGI::Liteだと150-160rq/s位までは持ちこたえられるとの結果を得ましたので、
CGI::Lite版を採用することに決めました。(その時は、最大50rq/s程度が想定でしたが・・・)
で、今回これと同じ処理をするcgiに、Jsからajaxリクエストを投げるような構成を考えていたのですが、
そのテストの段で、上記の>>311のような問題に行き当たったわけです。
現実問題として、速度や負荷の観点から、今回もCGI::Liteで行こうと思ったのですが、上記のような問題のため
(prototype.jsを使う使わないに関係なく)CGI::Liteが使えないので困ったなぁ とゆう感じです。
( 実は、mod_perl+Apache2::Requestでは、同様の処理で 1800rq/s！ とかベンチ出たんですが、
実験的な環境のため、そのまま本番環境には投入できません。)
324:nobodyさん
08/06/25 10:26:42
>>323
当然考えているとは思うけど、CGI::Lite に手を入れてしまうのがリーズナブルなんじゃないかな。
parse_form_data() 内で、
$content_type eq 'application/x-www-form-urlencoded'
と判断しているので、これを =~ にでもすればいいだけなわけだし。
325:nobodyさん
08/06/25 13:14:34
簡単なパースしかしないなら、モジュール使わない方法もあるんじゃね？
326:nobodyさん
08/06/28 19:23:20
HTMLフォームから送信されてきた文字列の中からURLを探しだして
<a href=>のタグをくっつけたいんですが、cgiのURLとかで?が入ってると上手く置き換えできません。
これを回避する方法を教えていただければ幸いです。
$mojiretu =~ s/$url/<a href="$url">$url<\/a>/; #$ulに?が入ってると置き換えできない。
327:nobodyさん
08/06/28 19:59:00
>>326
上手く行くかどうかしらんし、根本的な解決にはならんかも知れんが、
$mojiretu =~ s/\Q$url\E/<a href="$url">$url<\/a>/;
328:nobodyさん
08/06/28 20:12:33
>>327
うはｗできた
ありがとおお！！
329:nobodyさん
08/06/28 22:15:55
「\E までのパターン指定メタ文字の意味を打ち消す」
ってどういう意味かな？
330:nobodyさん
08/06/28 22:29:45
$str="a?b";
のとき、
/$str/
が
/a?b/
じゃなくて、
/a\?b/
に展開されるようにしてくれる。
331:nobodyさん
08/06/28 22:33:22
？が「パターン指定メタ文字」なんだな、たぶん。
それで、？があると、そのあとに続く文字が
特別な意味をもつんだな。
だからそれをエスケープ？しなくてはならなくて、
そのための呪文という意味か。よくわかりました。
332:nobodyさん
08/06/28 22:50:41
>>331
>それで、？があると、そのあとに続く文字が
>特別な意味をもつんだな。
違うよw
ま、追い追い勉強しなw
333:nobodyさん
08/07/01 21:46:30
perl -MCPAN -e shellの後に、install Math::BaseCalcしたら、
make: *** [test_dynamic] エラー 255ってでるんだよ
どうしたら、解決出きるのか教えてください
334:nobodyさん
08/07/01 23:37:34
>>333
config で make program を変更してみるとか、、、フォースインストール
するとか、、、
俺の場合はMath::BaseCalcじゃないけど、makeでコケた奴はソースで手動で
コンパイルして入れたりもする。
335:nobodyさん
08/07/01 23:40:04
>>333
まずはインストール時のメッセージをじっくり調べてみてはいかがでしょう。
336:うっとりハムちゃん
08/07/05 00:33:32 NR2upuAB
すいません、おじゃまします。
cgiにアクセスした際に、同時に○○.phpを読み込む際のPerl記述を教えていただけると助かります。
よろしくおねがいします。
337:nobodyさん
08/07/05 09:04:26
つ system
つ ``
338:うっとりハムちゃん
08/07/05 13:03:49 NR2upuAB
レスありがとうございます！
例えば○○.php を読み込みたい（実行したい）場合、以下では無反応なのですが、間違っていますか？
system ("○○.php");
339:うっとりハムちゃん
08/07/05 13:38:38 NR2upuAB
説明不足で申し訳ないのですが、用途としては、
phpカウンターをcgi（掲示板）実行時にも
カウントさせたいのです。
IMGタグでphpを読み込んでもいいのですが、
これだと携帯で見た時に壊れた画像マークになっちゃうので。。。
それで、cgiを実行時にphpファイルも同時実行できないかと思い、困っています。
よろしくお願いします。
340:nobodyさん
08/07/05 14:13:13
携帯でそうなる理由を調べてそれを解消したほうが早い
systemで実行するなら/usr/local/bin/php xxx.phpとかだろうけど
それでキミの欲しいものが得られるのか？
http経由で呼ぶならそうすればいい
341:うっとりハムちゃん
08/07/05 15:00:49
できました！
とても助かりました！！
どうもありがとうございました。 m(_ _)m
342:nobodyさん
08/07/05 20:33:29
>>341
おめでとう。
何をどう変えてどのような望む動作が得られたのかはさっぱりわからんが。
343:nobodyさん
08/07/05 21:27:12
おそらく直に読んでカウンターが上がったんじゃないかと
344:うっとりハムちゃん
08/07/05 23:02:34 NR2upuAB
たびたびすいません （＞＜）
system ("/usr/local/bin/php ○○.php");
↑これで うまくできたのですが、他のレンタルサーバーでも使おうと思ってみたら、
そっちではphpを読み込んでくれず、ソースコードが丸ごと表示されちゃいました。
サーバーによって動作は異なるのでしょうか？
345:うっとりハムちゃん
08/07/06 01:29:25 +aL1pH4z
もしかして system の場合、何か終了（閉じる？）を記載しないといけないのでしょうか？
単純にphpカウンターを実行するだけでいいのですが。。。
346:nobodyさん
08/07/06 02:26:42
>>344
そりゃあんた、その違うレンサバとやらがphp対応なのかどうかと、
phpの実行パスが/usr/local/bin/phpとは限らんだろう。
サーバによっては、httpからはphp実行出来ても、ユーザー権限で直接実行出来ないように
設定されてる場合もあるし。
347:うっとりハムちゃん
08/07/06 02:40:09 +aL1pH4z
ありがとうございます。
サーバー会社に問い合わせたところ、
system ("/usr/local/bin/php ○○.php");
で動作しますと言われました。
パスに関してはあっているようです。