Edit report at https://bugs.php.net/bug.php?id=51983&edit=1

 ID:                 51983
 Updated 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
+Status:             Analyzed
 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:

After having analyzing comments, apache behaviour, here is what I propose for 
this case.

1- add a fpm configuration directive for each pool named "fastcgi_client". 
Possible values are "rfc3875", "apache_mod_fastcgi", 
"apache_mod_proxy_fcgi" or "backward_compatibility". Defaults to "rfc3875".

2- add a fpm configuration directive for each pool named "document_root". It 
can be set to a directory. Defaults to (null).

3- add a fpm configuration directive for each pool named "always_run_script". 
It can be set to a php file. Defaults to (null)

When a request is received:
/*
 *  Use a custom script to do some routage and other stuf
 *  In this case FPM does nothing but to passthrough fastcgi variables
 */
if (fpm.ini[always_run_script] is set) {
  return execute_php(fpm.ini[always_run_script])
}

/*
 *  override DOCUMENT_ROOT if document_root is set in the FPM config
 *  otherwise check the DOCUMENT_ROOT sent is a valid directory 
 */ 
if (fpm_ini[document_root] is set) {
  DOCUMENT_ROOT = fpm.ini[document_root]
  // no need to check if DIR exits as it's been done at conf check
} else {
  if (DOCUMENT_ROOT is not set) {
    return error500 "document root not set"
  }
  if (!is_dir(DOCUMENT_ROOT)) {
    return error500 "Documentroot not found or not a directory"
  }
}


if (fpm.ini[fastcgi_client] == "backward_compatibility") {
  /*
   * Use the same code as before (with microsoft clean up)
   * Will maybe be removed in a later release.
   */
   
  see fpm_main.c in function init_request_info()       

}else if (fpm.ini[fastcgi_client] == "apache_mod_fastcgi" or 
"apache_mod_proxy_fcgi") {
 /*
  *     *** mod_fastcgi ***
  *    
  *  SCRIPT_NAME is invalid  (/php5-fcgi)
  *  PATH_INFO is set to /test.php/more
  *  SCRIPT_FILENAME is invalid (/tmp/php5-fcgi)
  *  DOCUMENT_ROOT is set correctly
  *  PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO
  *  REQUEST_URI is set correctly
  *  QUERY_STRING is set correctly
  *  
  *  ==> use DOCUMENT_ROOT + PATH_INFO                           
  */

  /*
  *     *** mod_proxy_fcgi ***
  *    
  *  everything is buggy in mod_proxy_fcgi
  *  PATH_TRANSLATED is set only if proxy-fcgi-pathinfo is set
  *  PATH_TRANSLATED is set to "proxy:fcgi://host:port" + PATH_INFO
  *  sometimes PATH_TRANSLATED is set to "proxy:fcgi://host:port" + PATH_INFO*2
  *   --> we can rely on PATH_TRANSLATED no matter what
  *          
  *  PATH_INFO is set only if proxy-fcgi-pathinfo is set
  *  PATH_INFO is set to /test.php/more
  *  SCRIPT_NAME is empty if proxy-fcgi-pathinfo is set
  *  SCRIPT_NAME has the same value as PATH_INFO when proxy-fcgi-pathinfo is set
  *   --> we can rely on one of those value. They are the same depending on
  *       proxy-fcgi-pathinfo        
  *
  *  SCRIPT_FILENAME value is consistent and set to 
  *  "proxy:fcgi://host:port" + PATH_INFO
  *           
  *  DOCUMENT_ROOT is set correctly
  *  QUERY_STRING is set correctly  
  *      
  *  ==> we will use PATH_INFO or SCRIPT_NAME and DOCUMENT_ROOT  
  */

  if (fpm.ini[fastcgi_client] == "apache_mod_fastcgi") {
    unset SCRIPT_NAME /* will use PATH_INFO instead */ 
  }

  /* automatic detection for mod_proxy_fcgi */
  if (SCRIPT_NAME null or empty) {
    SCRIPT_NAME = PATH_INFO
    unset PATH_INFO
  }
  
  if (SCRIPT_NAME is empty) {
    return error500("SCRIPT_NAME or PATH_INFO not set")
  }

  /* override PATH_TRANSLATED */  
  PATH_TRANSLATED = DOCUMENT_ROOT + SCRIPT_NAME   
  
  if (php.ini[fix_pathinfo] == 1) {
    /*
     *  Try to determine SCRIPT_FILENAME and PATH_INFO from PATH_TRANSLATED     
 
     */      
     For each '/' in PATH_TRANSLATED begining from the end of the string {
       SCRIPT_FILENAME = path before the '/'
       PATH_INFO = path after the '/' (with the '/' included)
       if SCRIPT_FILENAME is a valid file {
         PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO
         return execute_php(SCRIPT_FILENAME)
       }
       return error404 "file not found"        
     }
  } else {
    /*
     *  Suppose PATH_TRANSLATED is DOCUMENT_ROOT + SCRIPT_NAME
     *  ignore PATH_TRANSLATED and PATH_INFO     
     */
     SCRIPT_FILENAME = PATH_TRANSLATED
     unset PATH_TRANSLATED
     return execute_php(SCRIPT_FILENAME)            
  }    

} else { /* rfc3875 */
  /*
   *  simple as descript in RFC 3875
   *  let PATH_INFO and PATH_TRANSLATED to their value
   *  change nothing as we are supposed to be rfc compliant :-)      
   */   
  
  if (SCRIPT_NAME not set) {
    return error500 "SCRIPT_NAME not set"
  }

  SCRIPT_FILENAME = DOCUMENT_ROOT + SCRIPT_NAME 
  return execute_php(SCRIPT_FILENAME)
}


- "rfc3875" makes things very easy and quick for nginx, lighthttpd and other 
compliant fastcgi clients. php.ini fix_pathinfo is not 
used in this case.

- "apache_mod_fastcgi" and "apache_mod_proxy_fcgi" makes the code cleaner for 
apache. Correct values are deducted. php.ini 
fix_pathinfo is still used. If path_info URL are not used, fix_pathinfo can be 
disabled to avoid doing useless and costy calls to 
stats(). It would be maybe possible to use only one value "apache" and detect 
which one is used. But I prefer not to to be able to 
differentiate them later if need (as proxy_mod_fcgi could hopefully be updated 
to fix some of its bugs)

- "backward_compatibility" for those who have older version of apache or else 
which is not compatible with the previous mode. 
Hopefully it won't be needed and will be removed in a later release.

what guys do you think ???

++ jerome


Previous Comments:
------------------------------------------------------------------------
[2011-10-30 21:03:58] mabi at gentoo dot org

What's the status of this? Any chance we can have that fixed for 5.4?

------------------------------------------------------------------------
[2011-07-20 09:16:43] konstantin at symbi dot org

IIS? FPM does not support Windows, and IIS does not support remote FastCGI. 
Either 
ISAPI or local FCGI (via the cgi-fcgi SAPI) are used togerher with IIS, there's 
nothing about fpm.

For all other known webservers, both Jerome's and my proposals should work fine 
AFAIK.

------------------------------------------------------------------------
[2011-07-20 09:08:14] slim at inbox dot lv

probably it is worth to have additional setting to set webserver in use and 
select appropriate handling method.
Something like "web_server = compliant | apache | iis | anything"
this will simplify appending of hacks for custom implementations of fastcgi 
protocol

------------------------------------------------------------------------
[2011-07-17 15:35:58] konstantin at symbi dot org

I remember I've seen a configuration which passed SCIPT_FILENAME but no 
DOCUMENT_ROOT. (In nginx, you can define any fastcgi variables in the 
configuraton file, there's nothing hardcoded). I have no idea how many such 
configurations exist, may be that one was the single of its kind in the world. 
But it would be definitely wrong to break anything in the 5.3.x branch.

Well, that extra ini setting is probably really unneeded. May be just leave 
support for SCRIPT_FILENAME (handle it always it if is not empty) in 5.3.x, and 
drop it in 5.4?

------------------------------------------------------------------------
[2011-07-17 15:29:46] f...@php.net

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

------------------------------------------------------------------------


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

Reply via email to