ID: 48746
Comment by: sant9442 at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Hi,
This is a note for the bug archives.
I just discovered that the bug reported in #49039 which was merged with
this bug entry, can also be reproduced when the web server spawning
PHP-CGI.EXE incorrectly prepares the CGI environment string:
PATH_INFO
The correct "official" (IETF) standard definition is in RFC 3875:
"The Common Gateway Interface (CGI) Version 1.1":
http://www.ietf.org/rfc/rfc3875
If PATH_INFO is incorrect, the function sapi_cgi_register_variables()
sapi\cgi\cgi_main.c, which effectively does:
PHP_SELF = SCRIPT_NAME + PATH_INFO
will potentially cause the same "No input file specified" behavior we
saw in bug #49039.
The original bug #49039 report indicated a script in a sub-folder name
with 3 letters, e.g.;
/public/pwe/test.php
would yield a file not found response.
It was found if the server-side document root was a junction point, the
no input file error was produced.
c:\web\HTTP\public\pwe
where C:\WEB\HTTP is a junction, like using SysInternals.com
Junction.EXE utility:
C:
CD \WEB
junction HTTP D:\WEB_SRC\HTTP_REV1.2.3.4
We internally use junctions in this way to test various versions of our
html templates.
Eventually it was determined by [email protected] the PHP 5.3 logic for
resolving junctions has some issues to address and that is when I last
left this issue until now.
Recently, in an independent report related to PHP_SELF, we found out
our web server was not creating the environment string PATH_INFO CGI
correctly per RFC 3875.
This serve issue was just fixed and after seeing how PHP expects
PHP_SELF to be created using PATH_INFO, I was curious if the web server
PATH_INFO fix also fixes #49039.
Well, indeed it appears that it does fix it, even when the document
root is a junction point.
For the curious, our WEB SERVER first supported real CGI binary
processes, no script maps, for example for a URI with:
http://example.com/cgi-bin/applet.exe/file.txt?p1=v1
its parts are:
SCRIPT_NAME = "/cgi-bin/applet.exe"
QUERY_STRING = "p1=v1"
PATH_INFO = "/file.txt"
if for the sake of example, the document root is:
DOCUMENT_ROOT = "c:\web\http"
then PATH_TRANSLATED is:
PATH_TRANSLATED = "c:\web\http\file.txt"
When script mapping support was added, including support for specific
PHP's SCRIPT_FILENAME environment string, a bug was apparently
introduced for creating PATH_INFO. So in an valid URI with a PHP script
map:
http://example.com/test.php/file.txt?p1=v2
Our web server correctly created:
DOCUMENT_ROOT = "c:\web\http"
SCRIPT_NAME = "/test.php"
QUERY_STRING = "p1=v1"
SCRIPT_FILENAME = "c:\web\http\test.php"
PATH_TRANSLATED = "c:\web\http\file.txt"
but incorrectly created:
PATH_INFO = "/test.php/file.txt"
So when PHP-CGI started and created PHP_SELF in cgi_main.c
PHP_SELF = SCRIPT_NAME + PATH_INFO
its value was now:
PHP_SELF = "/test.php/test.php/file.txt"
thus the "no input file found" PHP response.
As noted, this as fixed in our web sever, and it appears to resolve
also bug #49039. I am sure inadvertingly the junction point issues were
legit and being (and had been?) addressed, I am just nothing as it
another possible reason caused by a web server not correctly
implementing PATH_INFO per RFC 3875.
Previous Comments:
------------------------------------------------------------------------
[2009-09-14 18:49:29] [email protected]
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
The next snapshot (in 1-2h) will have the fix as in the tiny php build
I provided earlier.
------------------------------------------------------------------------
[2009-09-14 18:46:57] [email protected]
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=288339
Log: - Fix #48746, improve fix to support all possible cases (see
latest comment in the report)
------------------------------------------------------------------------
[2009-09-05 22:51:50] phpstuff at cresstone dot com
That build fixed it for me.
------------------------------------------------------------------------
[2009-09-05 18:10:32] [email protected]
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=288085
Log: - add test for #48746
------------------------------------------------------------------------
[2009-09-05 16:34:37] [email protected]
Please try using:
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-Win32-VC9-x86.zip
It is a striped down build (thread safe). Only CLI is available but no
worry, it behaves the same than apache in TS mode.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
