gpt4 book ai didi

Perl CGI 从对当前 URL 的不同请求中获取参数

转载 作者:行者123 更新时间:2023-12-02 02:20:57 26 4
gpt4 key购买 nike

这很奇怪。 :)

我有一个在 Apache 1.3 下运行的脚本,带有 mod_perl 的 Apache::PerlRun 选项。它使用标准的 CGI.pm 模块。它是繁忙服务器上的定期访问脚本,通过 https 访问。

URL 通常类似于...

/script.pl?action=edit&id=47049

然后以通常的方式将其引入 Perl...

my $action = $cgi->param("action");
my $id = $cgi->param("id");

这几年来一直很成功。然而,本周我们开始收到来自访问此脚本并获得空白页面的客户的支持请求。我们已经有如下一行,将当前 URL 放入我们用于客户报告页面问题的表单中......

$cgi->url(-query => 1);

当我们查看页面的源代码时,该命令的结果是相同的 URL,但具有完全不同的查询字符串。

/script.pl?action=login&user=foo&password=bar

我们认为来自系统其他地方完全不同的脚本的查询字符串。

无论这听起来多么疯狂,当用户访问带有查询字符串的 URL 时,脚本看到的查询字符串似乎来自之前对另一个脚本的请求。当然,脚本无法处理该操作并且不输出任何内容。

我们运行了一些自动化测试脚本来查看这种情况发生的频率,但并非每次都如此。更令人困惑的是,在 Apache 重新启动后,问题似乎最初完全消失,但后来又出现了。因此,不管是什么原因导致它都可以通过重新启动以某种方式得到缓解,但我们看不到 Apache 怎么可能接受一个用户的请求并将其与另一个用户混合。

最佳答案

这似乎是 Apache 1.3、mod_perl 1.31、CGI.pm 和 Apache::GTopLimit 的有趣组合。

去年 5 月针对 CGI.pm 记录了一个错误:RT #57184

其中还引用了 CGI.pm params not being cleared?

CGI.pm 注册一个清理处理程序以清理其所有缓存....(第 360 行)

$r->register_cleanup(\&CGI::_reset_globals);

Apache::GTopLimit(如错误报告中提到的 Apache::SizeLimit)也有这样的处理程序:

$r->post_connection(\&exit_if_too_big) if $r->is_main;

在 mod_perl 1.31 之前的版本中,post_connection 和 register_cleanup 似乎压入了堆栈,而在 1.31 中,GTopLimit 似乎破坏了 CGI.pm 条目。因此,如果您的 GTopLimit 函数因为 Apache 进程变大而触发,那么 CGI.pm 将不会被清理,让它在下一次返回相同的参数您使用它的时间。

解决办法好像是把CGI.pm的第360行改成;

$r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals);

显式地将处理程序推送到列表中。

我们重新启动 Apache 暂时解决了这个问题,因为它减少了所有进程的大小并且让 GTopLimit 没有理由启动。

我们假设它在过去几周出现了,因为我们通过新的开发增加了 Apache 进程的大小,其中包括一些以前没有的东西。

到目前为止的所有测试都表明这是问题所在,所以祈祷吧!

关于Perl CGI 从对当前 URL 的不同请求中获取参数,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8247492/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com