The value of SCRIPT_NAME is wrong in apache 2.0.x... To test it use apache-1.3.x with http://somewhere/printenv.cgi/http://otherplace then SCRIPT_NAME will be /printenv.cgi but with apache-2.0.39 it will be /printenv.cgi/http: This will also result in wrong values from the CGI module in perl ($Q->url(-absolute=>1);) and maybe in PHP somewhere else. I am also hunting a bug in PHP redirection (header('Location: ...')) but i am not sure yet if it's a problem in PHP or apache.
This is probably the same bug as reported to RedHat in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68125 In which case, PATH_TRANSLATED and SCRIPT_NAME are corrupted as well as PATH_INFO.
The reference provided by John Ellson does appear to be the same bug. The proximate cause problem is in the function ap_find_path_info in server/util_script.c. It assumes that the tails of the uri and the path_info arguments will match exactly. But in the example case, the uri argument is '/cgi-bin/env/http://bluh' and the path_info argument is '/http:/bluh' -- note that the other slash before the 'bluh' is missing. Apparently the path_info argument (which comes directly from the request structure) has been either garbled or inappropriately normalized. I don't know yet where this garbling occurs.
The normalized value is assigned to r->path_info during the call to ap_directory_walk. ap_directory_walk contains the following comment: /* XXX Notice that this forces path_info to be canonical. That might * not be desired by all apps. ... It would appear that any application that depends on the PATH_INFO from a uri such as 'http://www.plover.com/cgi-bin/myprogram/http://some.other.url/' falls into the category of "an app that does not desire this behavior." But there is still a bug, because ap_find_path_info assumes that the tails of the r->path_info and r->uri will match, and they don't, because the path_info was canonicalized in ap_directory_walk, but the r->uri was not canonicalized. The ap_directory_walk comment cited above continues: ... However, some of those same apps likely * have significant security holes. */ I believe this is referring to apps that might be invoked as http://perl.plover.com/cgi-bin/myapp/../../../../../../../../../etc/passwd. Canonicalizing this path may well save 'myapp' from a severe security problem. However, compressing repeated slashes from the path_info does not appear to have any analogous security benefit.
*** Bug 13783 has been marked as a duplicate of this bug. ***
2.0.46 as well as HEAD still have this problem.
*** Bug 20047 has been marked as a duplicate of this bug. ***
Created attachment 13169 [details] fix for SCRIPT_NAME, skips multiple-slashes in URI while matching against PATH_INFO (note: this doesn't fix PATH_INFO)
patch has only been tested against 2.1-HEAD, but should apply to 2.0-HEAD as well to fix the issue with PATH_INFO would require a bunch of more work (like including the functionality of apr_filepath_merge into ap_directory_walk)
Debian's apache2_2.0.52-2 has this problem as described. It can also be triggered by "%2f"s appearing after the script name with "AllowEncodedSlashes on", if the encoded slash abuts either unencoded slash or another %2f.
according to some CGI spec I recently found the somehow garbled PATH_INFO is legal so the proposed patch should indeed fix the bug
Patch Seems reasonable to me... Comments from the Crowd?
Committed patch to HEAD.
Note that the PATH_INFO issue must still be fixed here. Bug #20047 is about PATH_INFO, but it has been marked as a duplicate of this one. Thus, either we fix it here, or we open a new bug report for it. I do not believe that a PATH_INFO of "foo//bar" should be equivalent to "foo/bar". Many existing applications certainly do not think so.
Hello, I am the author of the Perl CGI module and just ran into this bug myself. For those who are interested, I have created a workaround for the bug in CGI.pm version 3.11; it will return correct values for script_name(), path_info() and url() for versions of Apache both with and without this bug. However, it will not correct the situation described below in which ScriptAlias is used to pass additional path information to the CGI script in such a way that the info does not appear in REQUEST_URI.
Committed to HEAD two years ago, and I can't reproduce the problem. Assuming fixed.