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:
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
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2011-07-03 17:24:37] f...@php.net
I'm dequeuing FPM bugs. I've started with the simple ones. This one is on my
todo
list. I don't have an ETA right now.
++ Jerome
------------------------------------------------------------------------
[2011-07-03 14:33:23] fel...@php.net
What is the status of this?
------------------------------------------------------------------------
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
