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] [EMAIL PROTECTED] 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] [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;$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
