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?

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&section=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.

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&section=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.

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.