3

$.post("/url/", {wtf: 2}) でパラメーターが表示されない理由を理解しようとしています。

私はこのperlを使用しています：

use strict;
use CGI;

my $cgi = new CGI;
print $cgi->header("text/javascript");
print "'no'";

use Data::Dumper;
warn Dumper({ (map {$_=>$cgi->param($_ )} $cgi->param), postdata=>$cgi->param("POSTDATA") });

$.get("/url", {wtf: 2}) を発行すると、期待どおりの結果が得られ、ログで wtf が 2 であることがわかります。$.post("/url/", {wtf: 2}) を使用すると、パラメーターがまったく取得されないようです (ログに $VAR1 = { postdata=>undef } のみが表示されます)。

私は何が欠けていますか？

Firebug は、Transfer-Encoding が「chunked」であり、Content-Type が「application/x-www-form-urlencoded; charset=UTF-8」であることを明らかにしています。さらに、[投稿] タブにはリクエストの引数が表示されているようですが、CGI からの喜びはありません。

4

3 に答える 3

4

結果が application/x-www-form-urlencoded でも multipart/form-data でもない可能性があります。CGI docには、これについて次のように書かれています。

POST されたデータのタイプが application/x-www-form-urlencoded または multipart/form-data でない場合、POST されたデータは処理されず、代わりに POSTDATA という名前のパラメーターでそのまま返されます。それを取得するには、次のようなコードを使用します。

    my $data = $query->param('POSTDATA');
于 2009-02-24T22:40:29.910 に答える
2

代わりに CGI::Lite を使用していましたが、同じ問題がありました。

jquery の .post 関数は、明示的に設定されていても、フォームのコンテンツ タイプをオーバーライドしているようです。単純な「ngrep」により、常に次のようになることが明らかになりました。

application/x-www-form-urlencoded; charset=UTF-8

問題は、CGI::Lite モジュールが'application/x-www-form-urlencoded' (つまり、charset ビットなし) のみの正確な一致を期待していたことです。

このコード行を CGI/Lite.pm の完全一致から正規表現一致に変更すると、うまくいきました。

#($content_type eq 'application/x-www-form-urlencoded')) {
($content_type =~  /application\/x-www-form-urlencoded/)) {
于 2011-09-07T10:04:55.000 に答える
2

Linux ボックスにアクセスできる場合は、'nc' (netcat) を設定してポート 80 でリッスンし、受信している生のリクエストを確認できます。

ただし、サーバー側の問題だと思います。おそらく、いくつかのApache構成が干渉していますか? 申し訳ありませんが、これ以上お役に立てません。

于 2009-02-25T21:32:36.243 に答える