You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Jim Patterson <Ji...@Cognos.COM> on 1998/02/09 22:35:15 UTC
general/1786: CGI SCRIPT_NAME variable includes extraneous information
>Number: 1786
>Category: general
>Synopsis: CGI SCRIPT_NAME variable includes extraneous information
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Mon Feb 9 13:40:01 PST 1998
>Last-Modified:
>Originator: Jim.Patterson@Cognos.COM
>Organization:
apache
>Release: 1.3B3
>Environment:
Windows NT 4.0 Service Pack 3
Visual C++ 4.0
>Description:
The SCRIPT_NAME variable passed to CGI scripts is sometimes faulty; it contains
information that is duplicated in PATH_INFO. The problem seems to be that the
routine that constructs SCRIPT_NAME by matching the trailing PATH_INFO doesn't
take into consideration some of the modifications done by the URI parsing
functions to extract PATH_INFO in the first place. Specifically:
- if the URI contains trailing slashes, these are dropped to derive PATH_INFO
causing the match to fail.
- If the PATH_INFO portion contains upper case characters, the match also fails
since it is case-sensitive and the URI variable is by this time downshifted.
(This second problem seems to be WIN32 specific, the downshifting is done in
os/win32/util_win32.c{os_canonical_filename}).
This second problem seems to be a more serious problem but in fact is already report
it seems; see PR#1506.
The current logic downshifts the entire URI up to the query specification. It
really should only downshift only the "filename" portion. It would make sense
to "canonize" the PATH_TRANSLATED variable as well, but not PATH_INFO since it
may not be an actual pathname.
>How-To-Repeat:
I'm using this variation of the old "show environment variable " technique:
/cgi-bin/SHOWENV.BAT:
@echo off
echo content: text/plain
echo:
set
You can see the problem with either of the following URLs. Note that part of
PATH_INFO remains in SCRIPT_NAME in a slightly altered from. In one case,
SCRIPT_NAME has dropped the trailing slash; in the other, the PATH_INFO
information has been downshifted.
http://localhost/cgi-bin/showenv.bat/some/information/
http://localhost/cgi-bin/showenv.bat/Some/Information
>Fix:
Fixes:
In util_script.c function find_path_info:
- skip trailing slashes in the REQUEST_URI.
In util_win32.c function canonical_filename and sub_canonical_filename:
- Move the downshift logic to sub_canonical_filename so that it applies only to the actual filename portion.
(If PR#1506 has been fixed, then this change is apparently not needed).
Here is a patch:
*** os/win32/util_win32.c-orig Mon Feb 9 11:04:30 1998
--- os/win32/util_win32.c Mon Feb 9 12:14:16 1998
***************
*** 48,58 ****
--- 48,65 ----
strcpy(szCanon,buf);
szCanon[2]='/';
szCanon[3]='\0';
+ strlwr(szCanon);
}
if(h == INVALID_HANDLE_VALUE)
+ {
strcat(szCanon,szFilePart);
+ }
else
+ {
+ strlwr(d.cFileName);
strcat(szCanon,d.cFileName);
+ }
+
}
API_EXPORT(char *) os_canonical_filename(pool *pPool,const char *szFile)
***************
*** 60,66 ****
char buf[_MAX_PATH];
sub_canonical_filename(buf,szFile);
- strlwr(buf);
return pstrdup(pPool,buf);
}
--- 67,72 ----
*** main/util_script.c-orig Sun Nov 16 07:45:22 1997
--- main/util_script.c Mon Feb 9 11:13:38 1998
***************
*** 250,255 ****
--- 250,258 ----
int lu = strlen(uri);
int lp = strlen(path_info);
+ while (lu && uri[lu-1] == '/')
+ --lu;
+
while (lu-- && lp-- && uri[lu] == path_info[lp]);
if (lu == -1)
%0
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]