ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
-Status: Feedback
+Status: Bogus
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
And let close that one as well.
Please see #48746. Same issue, all discussions/feedbacks will be
followed there.
Previous Comments:
------------------------------------------------------------------------
[2009-10-02 15:12:17] paj...@php.net
@patrick dot boens at latosensu dot be
Why don't you try a snapshot? It is fixed in SVN.
------------------------------------------------------------------------
[2009-10-02 15:05:23] patrick dot boens at latosensu dot be
This bug is actually preventing us from using 5.3 at all! We have a
framework that is used for ±60 sites; each of them contains a junction
that points to 1 single instance of the framework.
------------------------------------------------------------------------
[2009-09-22 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2009-09-20 04:12:18] sant9442 at gmail dot com
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 paj...@php.net 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.
------------------------------------------------------------------------
[2009-09-14 18:49:29] paj...@php.net
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.
------------------------------------------------------------------------
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
