Re: Logic in sapi/cgi/cgi_main.c

From: Date: Mon, 30 Apr 2001 02:05:53 +0000
Subject: Re: Logic in sapi/cgi/cgi_main.c
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-53079@lists.php.net to get a copy of this message
On Mon, 30 Apr 2001, Andi Gutmans wrote: > http://www.faqts.com/knowledge_base/view.phtml/aid/734/fid/37 > It sounds to me that you are right. That should probably just be request_uri. > I thought many people have used this $PHP_SELF so it's kind of strange that > there haven't been a zillion complaints. > Does anyone object to changing this behavior? > You'd think one of the authors of the faqt would have filed a bug also... Anyway, If no one objects by tonight, I'll go ahead make the change and wait to be flamed ;) -Sterling > Andi > > At 01:56 PM 4/29/2001 -0400, Sterling Hughes wrote: > > >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 > > > > > > > >-- > >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 > > >

« previous php.dev (#53079) next »