Re: [PHP-DEV] Logic in sapi/cgi/cgi_main.c
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?
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: [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]
--
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]
Re: [PHP-DEV] Logic in sapi/cgi/cgi_main.c
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: [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]
--
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-DEV] Logic in sapi/cgi/cgi_main.c
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]
Re: [PHP-DEV] 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.
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]
Re: [PHP-DEV] 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: [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]
