3

我的网络主机拒绝帮助我解决这个问题，所以我来这里寻求一些“黑盒调试”的帮助。这是我发送给他们的内容的编辑版本：

我在 dreamhost 有两个（除其他外）域：

1) thefigtrees.net 2) shouldivoteformccain.com

我今天注意到，当我在 #1 上托管 CGI 脚本时，当 CGI 脚本运行时，作为 QUERY_STRING 环境变量传递给它的 HTTP GET 查询字符串已经被 URL 解码。这是一个问题，因为这意味着标准 CGI 库（例如 perl 的 CGI.pm）将尝试在 & 符号上拆分，然后对字符串本身进行解码。这有两个潜在的问题：

1）字符串是双重解码的，所以如果一个值被提交给脚本，例如“%2525”，它最终会被视为“%”（解码两次）而不是“%25”（解码一次）

2）（更常见）如果提交的值中有一个＆符号，那么它将（正确）提交为％26，但QUERY_STRING env。变量会将其解码为“&”，然后 CGI 库将在该 & 符号处不正确地拆分查询字符串。这是个大问题！

http://thefigtrees.net/test.cgi上的脚本演示了这一点。它回显了调用它的环境变量。在浏览器中导航到：

http://thefigtrees.net/lee/test.cgi?x=y%26z

您可以看到 REQUEST_URI 正确包含 x=y%26z（未编码），但 QUERY_STRING 已将其解码为 x=y&z。如果我在域 #2 ( http://www.shoulddivoteformccain.com/test.cgi?x=y%26z )重复测试， 我会看到 QUERY_STRING 仍未解码，因此 CGI.pm 然后会正确拆分和解码。

我尝试在两者上禁用我的 .htaccess 文件以确保这不是问题，并且没有发现任何区别。

由于我的网络主机似乎不愿意帮助我，任何人都可以推测造成这种情况的潜在原因吗？

谢谢，李

4

2 回答 2

1

我在 Apache 中也有同样的行为。

我相信如果安装了 mod_rewrite 会自动解码 URL，但是，即使没有它，我也看到了自动解码行为。我还没有找到另一个罪魁祸首。

一种常见的解决方法是对输入参数进行双重编码（利用在未编码的 URL 上调用时 URL 解码是安全的）。

于 2010-01-25T22:45:03.397 回答
0

好奇的。从这里我所看到的任何东西都不会给我们一个线索，为什么会发生这种情况......我只能确认这是一个环境错误，并怀疑可能是配置差异，比如可能重写规则。

根据 CGI 1.1，这种解码应该只发生在 SCRIPT-NAME 和 PATH-INFO，而不是 QUERY-STRING。发生这种情况毫无意义且令人讨厌，但这就是规范。使用 REQUEST-URI 而不是那些可用的变量（即 Apache）是您想要在路径部分中放置越界和 Unicode 字符的地方的常见解决方法，因此对查询字符串执行相同操作可能是合理的直到主机提供某种解决方案。

这些天VPS很便宜...

于 2009-01-15T01:15:48.590 回答