Bug #79027 for CGI: PATH_INFO is not removed if it contains a double slash

OK, I found what's wrong in CGI.pm (3.59, but I'm pretty sure 3.60 is affected too). In the url() subroutine, $self->path_info and $ENV{PATH_INFO} do not return the same string: $self->path_info returns the correct string, with the double //, while $ENV{PATH_INFO} returns the incorrect string, with the double // replaced by a single one. And so this code no longer does its job (line 2813 in CGI.pm 3.59): $uri =~ s/\Q$ENV{PATH_INFO}\E$// if defined $ENV{PATH_INFO}; If you replace this line by: $uri =~ s/\Q$path\E$// if defined $path; then everything works as expected. As you already defined $path at the top of url(), you should use it anyway. While you are on it (and unrelated to this issue), you have a useless $rewrite_in_use variable in the url() subroutine too. ;) I hope you can apply the change above asap. :)

Thanks for the report. Please submit a "Test::More" style test for the test case, and also a patch if you are able. Mark

This issue has been copied to: https://github.com/leejo/CGI.pm/issues/99 please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.

Rejecting. This is a backward compatibility hack, as per the comments in the module: 2966 # This function returns a potentially modified version of SCRIPT_NAME 2967 # and PATH_INFO. Some HTTP servers do sanitise the paths in those 2968 # variables. It is the case of at least Apache 2. If for instance the 2969 # user requests: /path/./to/script.cgi/x//y/z/../x?y, Apache will set: 2970 # REQUEST_URI=/path/./to/script.cgi/x//y/z/../x?y 2971 # SCRIPT_NAME=/path/to/env.cgi 2972 # PATH_INFO=/x/y/x 2973 # 2974 # This is all fine except that some bogus CGI scripts expect 2975 # PATH_INFO=/http://foo when the user requests 2976 # http://xxx/script.cgi/http://foo 2977 # 2978 # Old versions of this module used to accomodate with those scripts, so 2979 # this is why we do this here to keep those scripts backward compatible. 2980 # Basically, we accomodate with those scripts but within limits, that is 2981 # we only try to preserve the number of / that were provided by the user 2982 # if $REQUEST_URI and "$SCRIPT_NAME$PATH_INFO" only differ by the number 2983 # of consecutive /. 2984 # 2985 # So for instance, in: http://foo/x//y/script.cgi/a//b, we'll return a 2986 # script_name of /x//y/script.cgi and a path_info of /a//b, but in: 2987 # http://foo/./x//z/script.cgi/a/../b//c, we'll return the versions 2988 # possibly sanitised by the HTTP server, so in the case of Apache 2: 2989 # script_name == /foo/x/z/script.cgi and path_info == /b/c. 2990 # 2991 # Future versions of this module may no longer do that, so one should 2992 # avoid relying on the browser, proxy, server, and CGI.pm preserving the 2993 # number of consecutive slashes as no guarantee can be made there. If you can supply a automated test along with patch i will consider apply it. Otherwise i'm considering this a "won't fix".