Re: Logic in sapi/cgi/cgi_main.c

>Can you give an example of how it looks with request_uri and how it looks >with both? Then it'll be easier for someone like me who doesn't know the >standard too well to check the PHP manual and the HTTP standard to see >what >the correct behavior should be. > Well, I can't really test this, as I don't have windows, but here's my logic.... ;) To quote the bug report :: in your website such that it is contained somewhere within the subtree of a directory whose name ends with ".php". For example, on my box I had the file located at http://site/php/secure.php/version.php If you then look at the value of $PHP_SELF it is /php/secure.php/php/secure.php/version.php and NOT /php/secure.php/version.php as it should be. :: This appears in what I assume is the CGI version (only place possible). I then took a look at the code shown below. While most other sapi's register only the request_uri (or something else, given by the server's api itself), the code below provides an opportunity for the above condition to occur, if SCRIPT_NAME is invalid, ie, it gets cut off too soon, because of a odd directory name, then strcmp will not return the correct results and request_uri will un-necessarily be appended If you look at the first one, its with SCRIPT_NAME and REQUEST_URI (invalid), the second one is just the value of REQUEST_URI (valid)... -Sterling >Andi > >>At 07:55 AM 4/29/2001 -0400, Sterling Hughes wrote: >> >>I've taken a look at the code that registers $PHP_SELF in the CGI >>version, >>in accordance with bug 6491. I see the problem, its that on some server >>& >>OS combinations, the SCRIPT_NAME environment variable is incorrectly set >>and therefore the below code exhibits the bug (the strcmp() should >>avoid the request_uri being tagged on, but because the SCRIPT_NAME is >>invalid, it doesn't happen the two don't match, and the REQUEST_URI is >>incorrectly tagged on). >> >>It seems like the logical fix to this would to be just registering the >>REQUEST_URI as the PHP_SELF, however, I don't know this code to well, >>could one of the authors explain the reasoning behind prepending the >>SCRIPT_NAME when FORCE_CGI_REDIRECT is not enabled? >> >>-Sterling >> >> >>Related Code: >> >>#if FORCE_CGI_REDIRECT >> php_register_variable("PHP_SELF", (SG(request_info).request_uri ? >> SG(request_info).request_uri:""), track_vars_array ELS_CC PLS_CC); >>#else >> { >> char *sn; >> char *val; >> int l=0; >> >> sn = getenv("SCRIPT_NAME"); >> pi = SG(request_info).request_uri; >> if (sn) >> l += strlen(sn); >> if (pi) >> l += strlen(pi); >> if (pi && sn && !strcmp(pi, sn)) { >> l -= strlen(pi); >> pi = NULL; >> } >> val = emalloc(l + 1); >> sprintf(val, "%s%s", (sn ? sn : ""), (pi ? pi : "")); /* >> SAFE */ >> php_register_variable("PHP_SELF", val, track_vars_array ELS_CC >>PLS_CC); >> efree(val); >> } >>#endif >> >> >> >-- >>PHP Development Mailing List <http://www.php.net/> >>To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net >>For additional commands, e-mail: php-dev-help@lists.php.net >>To contact the list administrators, e-mail: php-list-admin@lists.php.net > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net >For additional commands, e-mail: php-dev-help@lists.php.net >To contact the list administrators, e-mail: php-list-admin@lists.php.net