Bug 10775 - SCRIPT_NAME wrong value
Summary: SCRIPT_NAME wrong value
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0-HEAD
Hardware: All Linux
: P1 critical with 5 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
: 20047 (view as bug list)
Depends on:
Reported: 2002-07-13 18:37 UTC by Sven Goldt
Modified: 2007-07-20 01:41 UTC (History)
5 users (show)

fix for SCRIPT_NAME, skips multiple-slashes in URI while matching against PATH_INFO (note: this doesn't fix PATH_INFO) (471 bytes, patch)
2004-10-21 19:02 UTC, Christian Schubert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Goldt 2002-07-13 18:37:06 UTC
The value of SCRIPT_NAME is wrong in apache 2.0.x...
To test it use apache-1.3.x with 
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 

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.
Comment 1 John Ellson 2002-07-23 22:01:38 UTC
This is probably the same bug as reported to RedHat in:


In which case, PATH_TRANSLATED and SCRIPT_NAME are corrupted as well as PATH_INFO.
Comment 2 Mark Jason Dominus 2002-08-10 04:34:33 UTC
 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.
Comment 3 Mark Jason Dominus 2002-08-10 05:20:22 UTC
The normalized value is assigned to r->path_info
during the call to ap_directory_walk.  ap_directory_walk contains the following

    /* 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
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.

Comment 4 Stefan Bodewig 2002-10-21 07:07:30 UTC
*** Bug 13783 has been marked as a duplicate of this bug. ***
Comment 5 Jeff Trawick 2003-06-23 23:57:32 UTC
2.0.46 as well as HEAD still have this problem.
Comment 6 Paul Querna 2004-08-30 10:25:07 UTC
*** Bug 20047 has been marked as a duplicate of this bug. ***
Comment 7 Christian Schubert 2004-10-21 19:02:54 UTC
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)
Comment 8 Christian Schubert 2004-10-21 19:05:49 UTC
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)
Comment 9 Andrew Chadwick 2004-11-14 18:32:54 UTC
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.
Comment 10 Christian Schubert 2005-02-19 18:23:56 UTC
according to some CGI spec I recently found the somehow garbled PATH_INFO is 
legal so the proposed patch should indeed fix the bug  
Comment 11 Paul Querna 2005-04-06 22:55:32 UTC
Patch Seems reasonable to me... Comments from the Crowd?
Comment 12 Nick Kew 2005-06-21 12:53:59 UTC
Committed patch to HEAD. 
Comment 13 James Marshall 2005-07-03 06:52:58 UTC
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.
Comment 14 Lincoln Stein 2005-08-03 23:22:42 UTC
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. 
Comment 15 Nick Kew 2007-07-20 01:41:00 UTC
Committed to HEAD two years ago, and I can't reproduce the problem.  Assuming fixed.