Edit report at https://bugs.php.net/bug.php?id=51983&edit=1
ID: 51983
Comment by: f...@php.net
Reported by: konstantin at symbi dot org
Summary: [fpm sapi] pm.status_path not working when
cgi.fix_pathinfo=1
Status: Assigned
Type: Bug
Package: FPM related
Operating System: Any
PHP Version: 5.3SVN-2010-06-03 (snap)
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
hi,
thx for the feedback. For SCRIPT_FILENAME, I know it became a pseudo standard.
But as the concatenation of DOCUMENT_ROOT and SCRIPT_NAME results in
SCRIPT_FILENAME, I don't really see why you want to keep it with yet another
fpm
configuration line ? Maybe I missed something :)
++ Jerome
Previous Comments:
------------------------------------------------------------------------
[2011-07-17 14:19:13] konstantin at symbi dot org
Hello,
Here are a few quick thoughts.
1) The fix_pathinfo stuff has been implemented a long ago, and it's main
purpose
was to workaround the bugs of web servers used 10 years ago. It was
developed with the CGI exec()s in mind so the performance impact caused by
multiple stat()s was not so important. I see no reason to keep it
nowadays.
2) The patch I have proposed hase a bug mentioned in a comment above, that must
be fixed. I personally just use fix_patninfo=0 now ;)
3) The CGI protocol itself has been developed (as far as I understand) with a
thought that there's some monolithic application which takes PATH_INFO,
parses it, does something and prints the results. With PHP applications,
there's
usually another case - we need to map the request variables to a physical
path to the php script, the same way as web server SAPIs do. It does not
conform
to any RFCs but that's how people DO use PHP, and that's a behavior everyone
expects in 99.9999% cases.
4) The non-standard SCRIPT_FILENAME fastcgi variable is widely used in many
configurations, and there are standard config samples for nginx etc which rely
on
the fact that it has been working for years.
5) Your proposal seems mostly OK but I'd prefer if the SCRIPT_FILENAME remains
supported.
My proposal would be close to yours:
I. Add the 'fcgi.accept_script_filename' per-pool ini setting, default true;
II. Add the document_root.override per-pool ini setting, default empty.
III. Remove all the fix_pathinfo stuff, and change the corresponding parts of
the init_request_info function according to the pseudocode:
function get_script_filename(ini, Env) {
var script_filename;
if (ini["fcgi.accept_script_filename"] == true && Env["SCRIPT_FILENAME"] is
not empty) {
script_filename = Env["SCRIPT_FILENAME"];
} else {
doc_root = undefined;
assert(Env["SCRIPT_NAME"] is not empty); // *
if (ini["document_root.override"] is not empty) {
doc_root = ini["document_root.override"];
} else {
assert(Env["DOCUMENT_ROOT"] is not empty);
doc_root = Env["DOCUMENT_ROOT"];
}
script_filename = concat(doc_root, Env["SCRIPT_NAME"]);
}
return script_filename;
}
*) assert() means 'respond with status 500 if assertion fails'.
The RFC3875 compliance can be achieved by defining document_root.override and
setting fcgi.accept_script_filename = false.
------------------------------------------------------------------------
[2011-07-16 19:37:25] f...@php.net
If FPM would be RFC 3875 compliant, it should:
- set document_root in its own configuration
- execute the script set by concatening its own document_root and SCRIPT_NAME
As all web servers are sending DOCUMENT_ROOT correctely, FPM should:
- execute the script set by concatening DOCUMENT_ROOT and SCRIPT_NAME
In this two cases, nginx and lighttpd would still work, mod_fastcgi should work
depending on how it's being used and proxy_mod_fcgi whould just not work.
as apache 2.3 is still beta, I hope we could have them change mod_proxy_fcgi
behaviour
in order to be RFC 3875 compliant... (I've opened a bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51517)
but for mod_fastcgi this is more complicated. We can't forget it because it's
used with FPM (just google apache fpm)
How should we addresse that ? That is the question I don't have the answer to :(
But I have a proposal:
1- add a configuration directive on each pool named "document_root.override"
which is optional and default set to "true"
2- add a configuration directive on each pool named "document_root" which is
optional and default set to (null).
But it's mandatory if document_root.override is set.
This set the document_root for the current pool.
In fact, as the web server and FPM can be on a different server with a
different
filesystem organisation,
I really think that it's not the job of the webserver to set the document_root,
but it's up to nginx.
Does the webserver defines where a tomcat application servers find the files /
class it has to execute ? --> NO.
This configuration is made on the tomcat side.
FPM should not be exclusive, but this should be definitely possible (which is
not the case right now)
3- add a configuration directive on each pool named
"not_compliant_fcgi_web_server" which is optional and default set to "false"
So, when a request arrives
if (not_compliant_fcgi_web_server is set to "true") {
just act as now and nothing changes and all servers works.
} else { // new behaviour, RFC compliant
// determine the doc_root.
doc_root = (empty)
if (document_root.override is set to "false") {
doc_root = document_root
} else {
if (DOCUMENT_ROOT has been sent by the webserver) {
doc_root = DOCUMENT_ROOT
} else {
doc_root = document_root
}
}
if (doc_root is not empty and SCRIPT_NAME is not empty) {
execute script set by concatenation of doc_root and SCRIPT_NAME
} else {
returns a 500 and log the error to warn the web server administrator
}
}
Notes: the configuration directive names have been choosen as a first thought.
There is maybe changes to make.
what guys do you think ?
++ Jerome
------------------------------------------------------------------------
[2011-07-16 19:37:12] f...@php.net
but let's analyse all this:
FastCGI defines a communication protocol above CGI 1.1 (which is defined in RFC
3875).
So fastcgi client/servers should be RFC 3875 compliant
>From RFC 3875:
Usefull required request variables are:
- PATH_INFO
- PATH_TRANSLATED
- QUERY_STRING
- SCRIPT_NAME
And the variable which are NOT defined in the RFC:
- DOCUMENT_ROOT
- SCRIPT_FILENAME
- REQUEST_URI
Here is a comparison of common web server behaviour to see what values they
send
to FPM. See http://pastebin.com/tqFjUaiB
Conlusion:
Nginx and Lighttpd are fully RFC 3875 compliant and they add the following
variables:
- SCRIPT_FILENAME
- DOCUMENT_ROOT
- REQUEST_URI
Note: nginx should set PATH_INFO event if it's null as describe in the RFC. But
this breaks nothing. So we can forgive him.
mod_fastcgi is acting as nginx and lighttpd only with the following
configuration:
<VirtualHost *:82>
DocumentRoot /home/fat/web/docs/php
FastCgiExternalServer /home/fat/web/docs/php -host 127.0.0.1:9000
</VirtualHost>
but in this case, all request are sent to FPM and this is NOT what common users
want to do.
In order to send only php request, users can use the following configuration:
<VirtualHost *:82>
DocumentRoot /home/fat/web/docs/php
<Location "/php-fpm">
Options +ExecCGI
Order Deny,Allow
Deny from All
Allow from ENV=REDIRECT_STATUS
</Location>
FastCgiExternalServer /php-fpm-handler -host 127.0.0.1:9000
AddType application/x-httpd-php .php
Action application/x-httpd-php /php-fpm
ScriptAlias /php-fpm /php-fpm-handler
</VirtualHost>
In this case, mod_fastcgi is not RFC 3875 compliant:
- DOCUMENT_ROOT, REQUEST_URI and QUERY_STRING are set correctely
- SCRIPT_FILENAME, SCRIPT_NAME, PATH_INFO, PATH_TRANSLATED have just wrong
values
mod_proxy_fcgi is also not RFC 3875 compliant:
- DOCUMENT_ROOT, REQUEST_URI and QUERY_STRING are set correctely
- SCRIPT_FILENAME, SCRIPT_NAME, PATH_INFO, PATH_TRANSLATED have just wrong
values
SCRIPT_NAME is even empty when apache env var proxy-fcgi-pathinfo is set
------------------------------------------------------------------------
[2011-07-16 19:34:19] f...@php.net
Warning: the following comment is very long. Take time to read it and don't
hesitate to ask me for details questions.
Notes: I've not been able to put it all in one comment (it's detected as spam).
So I've split it into several comments.
I just review de patch and there is a problem.
It does not work with mod_fastcgi except when mod_fastcgi is configured as
commented before:
DocumentRoot "/var/www"
FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock
<Directory /var/www>
Options FollowSymLinks +ExecCGI
AllowOverride All
Order Allow,Deny
Allow from all
</Directory>
Setting this make all requests to be forward to php-fpm and that is definitely
NOT what common configurations aim to do.
More common mod_fastcgi configuration would be something like:
ScriptAlias /fcgi-bin/ /usr/local/apache2/fcgi-bin/
FastCGIExternalServer /usr/local/apache2/fcgi-bin/php-cgi -host 127.0.0.1:9000
AddHandler php-fastcgi .php
Action php-fastcgi /fcgi-bin/php-cgi
and in this case, the patch does not work.
------------------------------------------------------------------------
[2011-07-03 17:28:11] fel...@php.net
Ah okay, I was wondering if it already has been closed. Thanks.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=51983
--
Edit this bug report at https://bugs.php.net/bug.php?id=51983&edit=1
