>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: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
