【发布时间】:2013-03-08 07:01:40
【问题描述】:
当我得到答案时,我可能会发布更多问题,但是就这样吧!
我目前正在尝试对我的大学用来自动下载包含 SAT 分数数据的文件的 Perl 脚本进行故障排除。
这个想法是阅读某个帐户中的电子邮件;拉出循环编号(在 URL 中使用);拼凑多个网址;然后使用LWP::UserAgent 从服务器获取文件并对它们执行其他 Perl 魔法。
在我的调查中,我确定手动输入 URL(从而限制用户运行的脚本,每次都替换循环编号)确实有效。
在检查发回的响应对象时,我注意到(首先)失败的请求中缺少以下行:
'_uri_canonical' => $VAR1->{'_request'}{'_uri'}
但是它存在于成功的请求中。
如果你们中的任何人能告诉我为什么在不成功的请求中缺少这一行,我会感谢你们,但这不是我要问的。
我的问题与进一步调查有关,以了解它被拒绝的原因。
在LWP::UserAgent 的文档中,我注意到了这一点:
LWP 内部生成的错误响应会将“Client-Warning”标头设置为值“Internal response”。如果您需要将这些内部响应与远程服务器实际生成的响应区分开来,则需要测试此标头值。
我的问题:您如何实际测试该标头值? (请原谅我的无知;我是我大学 IT 部门的实习生)
【问题讨论】:
-
我误会了什么?我确定您知道
'_uri_canonical' => $VAR1->{'_request'}{'_uri'}不是标题字段。它看起来像Data::Dumper的输出,用于调试程序中的某些内容。我需要了解您的意图并查看更多不适合您的 Perl 代码。 -
_uri_canonical的缺失仅仅意味着没有人在该特定请求上调用uri_canonical方法,这可能与不成功请求的情况有关。不工作的脚本可能正在发出该调用,或者它可能类似于HTTP::Config(因为有人说$ua->add_handler而发生这种情况)。如果没有更多的上下文,真的很难判断。 -
感谢您的澄清。正如您所怀疑的,这实际上是 Data::Dumper 的输出。这是给我的代码:
codeforeach my $msgnum (sort keys %cycles) { my $url = $site.$cycles{$msgnum}{cycle};我的 $response = $browser->get($url);我的 $gpg = $response->内容;报告($cycles{$msgnum}{cycle}, $url, $gpg, Dumper($response)); (如果格式不正确,我深表歉意。)我上面提到的 uri_canonical 位来自传递给 Report() sr 的最后一个参数。 $browser 是一个基本的 LWP::UserAgent。
标签: perl httpresponse lwp-useragent