#12608 [Com]: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS
| From: | xxx-simpsons1501 at hotmail dot com | Date: | Tue, 20 Jul 2004 15:12:39 +0000 |
| Subject: | #12608 [Com]: $REDIRECT_QUERY_STRING isn't parsed into $HTTP_GET_VARS | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-63169@lists.php.net to get a copy of this message | ||
ID: 12608
Comment by: xxx-simpsons1501 at hotmail dot com
Reported By: havardda-dev at orakel dot ntnu dot no
Status: Bogus
Bug Type: Variables related
Operating System: Debian potato GNU/Linux
PHP Version: 4.0.5
New Comment:
<a href=http://xanonym-army-oralse.da.ru>simpsons
xxx</a>
Previous Comments:
------------------------------------------------------------------------
[2001-08-07 17:38:38] jeroen@php.net
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.
------------------------------------------------------------------------
[2001-08-07 12:22:14] havardda-dev at orakel dot ntnu dot no
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=33255§ion=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] havardda-dev at orakel dot ntnu dot no
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=33255§ion=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] andy@php.net
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;$i<count($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] havardda-dev at orakel dot ntnu dot no
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=12608&edit=1