[PHP-DEV] Bug #12608 Updated: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS

2001-08-07 Thread andy

ID: 12608
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Variables related
Old Operating System: Debian potato GNU/Linux
Operating System: Debian potato GNU/Linux
PHP Version: 4.0.5
New Comment:

I don't know if I read this right, because it was a bit confusing,
but I'll take a shot.

$HTTP_GET_VARS parses the query string for the current page...
I can't think of a good example right now, but it could mess things
up if REDIRECT_QUERY_STRING broke up into HTTP_GET_VARS.

If you wanted to do something like that try a script like the following...
[not tested]
?
$splitby=split(,$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING]);
for ($i=0;$icount($splitby);$i++){
$splitfurther=split(=,$splitby[$i]);
$$splitfurther[0]=$splitfurther=[1];
}

This should put the REDIRECT_QUERY_STRING into variables,
like if the redirect query string was foo=bar, then your script should
parse it so that $foo=bar;

Does this help?



Previous Comments:


[2001-08-06 18:57:51] [EMAIL PROTECTED]

The summary field really says it all:
Upon writing a customized 404 script, I stumbled upon the fact that the 
$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING] didn't break up into $HTTP_GET_VARS, even 
though one would expect it to. 
Is there a reason to this? I tried going through the bug database and the email 
archives, but I didn't seem to find anything similar. My apologies if this still is a 
second bug report, or if there's some perfectly valid explanation given somewhere.

Thanks for a great tool, by the way.





Edit this bug report at http://bugs.php.net/?id=12608edit=1


-- 
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] Bug #12608 Updated: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS

2001-08-07 Thread havardda-dev

ID: 12608
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Variables related
Operating System: Debian potato GNU/Linux
PHP Version: 4.0.5
New Comment:

Thanks for the reply.

Sorry that the first post was confusing, I'll try explaining my situation more 
thoroughly:
I have a site that generates dynamic content. I don't want long, not-user-friendly 
urls of the form http://../project/read.php?objectid=33255section=2355;, so I've 
written a custom 404 script that lets me do a 
http://.../project/sectionname/objectname; in true Jakob Nielsen spirit.

So far so good, but say I want to append ?lang=en (or any get variable) to the url? 
If I do, the 404 script doesn't see $HTTP_GET_VARS(it is empty), so I have to look at 
$RQS ($REDIRECT_QUERY_STRING), as per the original note.
This isn't really a problem, I use parse_str() to break up $RQS, and all is well.

So why all the hassle, if all is well? Well, because contrary to what you say, I think 
(but I may ofcoursly be wrong on this, it wouldn't be the first time :) that breaking 
up the query string into HTTP_GET_VARS would be a right thing. If I understand the 
whole 404 process correctly, there will never be a $QUERY_STRING (which normally is 
what ends up in HTTP_GET_VARS and $argv, I presume) in a 404 script, but instead a 
$REDIRECT_QUERY_STRING. If this is correct, using $REDIRECT_QUERY_STRING in the same 
manner as $QUERY_STRING is ok, because both cannot be set at the same time.

Please correct me if I'm wrong.


Previous Comments:


[2001-08-07 08:40:42] [EMAIL PROTECTED]

I don't know if I read this right, because it was a bit confusing,
but I'll take a shot.

$HTTP_GET_VARS parses the query string for the current page...
I can't think of a good example right now, but it could mess things
up if REDIRECT_QUERY_STRING broke up into HTTP_GET_VARS.

If you wanted to do something like that try a script like the following...
[not tested]
?
$splitby=split(,$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING]);
for ($i=0;$icount($splitby);$i++){
$splitfurther=split(=,$splitby[$i]);
$$splitfurther[0]=$splitfurther=[1];
}

This should put the REDIRECT_QUERY_STRING into variables,
like if the redirect query string was foo=bar, then your script should
parse it so that $foo=bar;

Does this help?





[2001-08-06 18:57:51] [EMAIL PROTECTED]

The summary field really says it all:
Upon writing a customized 404 script, I stumbled upon the fact that the 
$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING] didn't break up into $HTTP_GET_VARS, even 
though one would expect it to. 
Is there a reason to this? I tried going through the bug database and the email 
archives, but I didn't seem to find anything similar. My apologies if this still is a 
second bug report, or if there's some perfectly valid explanation given somewhere.

Thanks for a great tool, by the way.





Edit this bug report at http://bugs.php.net/?id=12608edit=1


-- 
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] Bug #12608 Updated: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS

2001-08-07 Thread havardda-dev

ID: 12608
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: Debian potato GNU/Linux
PHP Version: 4.0.5
New Comment:

Thanks for the reply.

Sorry that the first post was confusing, I'll try explaining my situation more 
thoroughly:
I have a site that generates dynamic content. I don't want long, not-user-friendly 
urls of the form http://../project/read.php?objectid=33255section=2355;, so I've 
written a custom 404 script that lets me do a 
http://.../project/sectionname/objectname; in true Jakob Nielsen spirit.

So far so good, but say I want to append ?lang=en (or any get variable) to the url? 
If I do, the 404 script doesn't see $HTTP_GET_VARS(it is empty), so I have to look at 
$RQS ($REDIRECT_QUERY_STRING), as per the original note.
This isn't really a problem, I use parse_str() to break up $RQS, and all is well.

So why all the hassle, if all is well? Well, because contrary to what you say, I think 
(but I may ofcoursly be wrong on this, it wouldn't be the first time :) that breaking 
up the query string into HTTP_GET_VARS would be a right thing. If I understand the 
whole 404 process correctly, there will never be a $QUERY_STRING (which normally is 
what ends up in HTTP_GET_VARS and $argv, I presume) in a 404 script, but instead a 
$REDIRECT_QUERY_STRING. If this is correct, using $REDIRECT_QUERY_STRING in the same 
manner as $QUERY_STRING is ok, because both cannot be set at the same time.

Please correct me if I'm wrong.


Previous Comments:


[2001-08-07 09:38:53] [EMAIL PROTECTED]

Thanks for the reply.

Sorry that the first post was confusing, I'll try explaining my situation more 
thoroughly:
I have a site that generates dynamic content. I don't want long, not-user-friendly 
urls of the form http://../project/read.php?objectid=33255section=2355;, so I've 
written a custom 404 script that lets me do a 
http://.../project/sectionname/objectname; in true Jakob Nielsen spirit.

So far so good, but say I want to append ?lang=en (or any get variable) to the url? 
If I do, the 404 script doesn't see $HTTP_GET_VARS(it is empty), so I have to look at 
$RQS ($REDIRECT_QUERY_STRING), as per the original note.
This isn't really a problem, I use parse_str() to break up $RQS, and all is well.

So why all the hassle, if all is well? Well, because contrary to what you say, I think 
(but I may ofcoursly be wrong on this, it wouldn't be the first time :) that breaking 
up the query string into HTTP_GET_VARS would be a right thing. If I understand the 
whole 404 process correctly, there will never be a $QUERY_STRING (which normally is 
what ends up in HTTP_GET_VARS and $argv, I presume) in a 404 script, but instead a 
$REDIRECT_QUERY_STRING. If this is correct, using $REDIRECT_QUERY_STRING in the same 
manner as $QUERY_STRING is ok, because both cannot be set at the same time.

Please correct me if I'm wrong.




[2001-08-07 08:40:42] [EMAIL PROTECTED]

I don't know if I read this right, because it was a bit confusing,
but I'll take a shot.

$HTTP_GET_VARS parses the query string for the current page...
I can't think of a good example right now, but it could mess things
up if REDIRECT_QUERY_STRING broke up into HTTP_GET_VARS.

If you wanted to do something like that try a script like the following...
[not tested]
?
$splitby=split(,$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING]);
for ($i=0;$icount($splitby);$i++){
$splitfurther=split(=,$splitby[$i]);
$$splitfurther[0]=$splitfurther=[1];
}

This should put the REDIRECT_QUERY_STRING into variables,
like if the redirect query string was foo=bar, then your script should
parse it so that $foo=bar;

Does this help?





[2001-08-06 18:57:51] [EMAIL PROTECTED]

The summary field really says it all:
Upon writing a customized 404 script, I stumbled upon the fact that the 
$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING] didn't break up into $HTTP_GET_VARS, even 
though one would expect it to. 
Is there a reason to this? I tried going through the bug database and the email 
archives, but I didn't seem to find anything similar. My apologies if this still is a 
second bug report, or if there's some perfectly valid explanation given somewhere.

Thanks for a great tool, by the way.





Edit this bug report at http://bugs.php.net/?id=12608edit=1


-- 
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] Bug #12608 Updated: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS

2001-08-07 Thread jeroen

ID: 12608
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Variables related
Operating System: Debian potato GNU/Linux
PHP Version: 4.0.5
New Comment:

It is the responsibility of the 404-script to pass on the query string (as far as 
relevant). This is not a bug, the original query string is not anymore a 
get-variable-list, only the new query string is.

Use urlencode, implode, and that kind of functions to append the 'old'query-string to 
the new one.

Previous Comments:


[2001-08-07 12:22:14] [EMAIL PROTECTED]

Thanks for the reply.

Sorry that the first post was confusing, I'll try explaining my situation more 
thoroughly:
I have a site that generates dynamic content. I don't want long, not-user-friendly 
urls of the form http://../project/read.php?objectid=33255section=2355;, so I've 
written a custom 404 script that lets me do a 
http://.../project/sectionname/objectname; in true Jakob Nielsen spirit.

So far so good, but say I want to append ?lang=en (or any get variable) to the url? 
If I do, the 404 script doesn't see $HTTP_GET_VARS(it is empty), so I have to look at 
$RQS ($REDIRECT_QUERY_STRING), as per the original note.
This isn't really a problem, I use parse_str() to break up $RQS, and all is well.

So why all the hassle, if all is well? Well, because contrary to what you say, I think 
(but I may ofcoursly be wrong on this, it wouldn't be the first time :) that breaking 
up the query string into HTTP_GET_VARS would be a right thing. If I understand the 
whole 404 process correctly, there will never be a $QUERY_STRING (which normally is 
what ends up in HTTP_GET_VARS and $argv, I presume) in a 404 script, but instead a 
$REDIRECT_QUERY_STRING. If this is correct, using $REDIRECT_QUERY_STRING in the same 
manner as $QUERY_STRING is ok, because both cannot be set at the same time.

Please correct me if I'm wrong.




[2001-08-07 09:38:53] [EMAIL PROTECTED]

Thanks for the reply.

Sorry that the first post was confusing, I'll try explaining my situation more 
thoroughly:
I have a site that generates dynamic content. I don't want long, not-user-friendly 
urls of the form http://../project/read.php?objectid=33255section=2355;, so I've 
written a custom 404 script that lets me do a 
http://.../project/sectionname/objectname; in true Jakob Nielsen spirit.

So far so good, but say I want to append ?lang=en (or any get variable) to the url? 
If I do, the 404 script doesn't see $HTTP_GET_VARS(it is empty), so I have to look at 
$RQS ($REDIRECT_QUERY_STRING), as per the original note.
This isn't really a problem, I use parse_str() to break up $RQS, and all is well.

So why all the hassle, if all is well? Well, because contrary to what you say, I think 
(but I may ofcoursly be wrong on this, it wouldn't be the first time :) that breaking 
up the query string into HTTP_GET_VARS would be a right thing. If I understand the 
whole 404 process correctly, there will never be a $QUERY_STRING (which normally is 
what ends up in HTTP_GET_VARS and $argv, I presume) in a 404 script, but instead a 
$REDIRECT_QUERY_STRING. If this is correct, using $REDIRECT_QUERY_STRING in the same 
manner as $QUERY_STRING is ok, because both cannot be set at the same time.

Please correct me if I'm wrong.




[2001-08-07 08:40:42] [EMAIL PROTECTED]

I don't know if I read this right, because it was a bit confusing,
but I'll take a shot.

$HTTP_GET_VARS parses the query string for the current page...
I can't think of a good example right now, but it could mess things
up if REDIRECT_QUERY_STRING broke up into HTTP_GET_VARS.

If you wanted to do something like that try a script like the following...
[not tested]
?
$splitby=split(,$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING]);
for ($i=0;$icount($splitby);$i++){
$splitfurther=split(=,$splitby[$i]);
$$splitfurther[0]=$splitfurther=[1];
}

This should put the REDIRECT_QUERY_STRING into variables,
like if the redirect query string was foo=bar, then your script should
parse it so that $foo=bar;

Does this help?





[2001-08-06 18:57:51] [EMAIL PROTECTED]

The summary field really says it all:
Upon writing a customized 404 script, I stumbled upon the fact that the 
$HTTP_SERVER_VARS[REDIRECT_QUERY_STRING] didn't break up into $HTTP_GET_VARS, even 
though one would expect it to. 
Is there a reason to this? I tried going through the bug database and the email 
archives, but I didn't seem to find anything similar. My apologies if this still is a 
second bug report, or if there's some perfectly valid explanation given somewhere.

Thanks for a great tool, by the way.