Variables in header("Location:");

[internetheaven]

Building a redirect script similar in concept to what seems to be how WW threads link out. I've got this:

<?php
$visitpage = $_SERVER['REQUEST_URI'];
$visitpage = str_replace("/js/visit.php?go=", "", $visitpage);
if (preg_match("/http/", $visitpage))
{
header("Location:['$visitpage']");
}
else
{
echo $visitpage;
}
?>

Obviously the outbound address is after the "go=" part of the URL. The preg_match makes sure that it is a URL not a wrong query string.

How do you insert a variable into the location redirect?

Thanks
Mike

[internetheaven]

Trial and error for an extra half hour and got:

Header( "Location: ".$visitpage);

which works.

[d40sithui]

unless im missing something here, it should be as simple as

header("Location: $visitpage");

[internetheaven]

header("Location: $visitpage");

did not work, it simply returned "$visitpage" as the destination URL.

Mike

[eelixduppy]

>> did not work, it simply returned "$visitpage" as the destination URL.

That doesn't make much sense; it should have worked that way as well as using concatentation like you did. Check the documentation on strings [us2.php.net] for additional information.

There's also a problem with the code that you have in your first post that doesn't have to do with the your initial problem, and I thought I'd just point this out. Grabbing the URL from the query string like you are doing can lead to redirecting problems because the URL may not be valid after all. For instance, consider the possibility that the URI contained the following:

/js/visit.php?go=http://www.example.com&var=something

When you do your replacement you will wind up redirecting to the following URL:

http://www.example.com&var=something

Which will still be deemed "correct" by your regex, as well. Obviously this is something that you'd want to avoid, so to do that you should just be using the $_GET [us2.php.net]['go'] super global as it will only be grabbing the 'http://www.example.com' part without having to removed the unnecessary data.

Then, as far as your regex goes, you should probably beef up that validation a little bit more so that it makes sure that what you have is an actually properly formatted URL. For instance, we could have the following as the value of $_GET['go']:

httpd.apache.org

Which, with your current regex would be considered valid, however, what we are really looking for as valid is the following:

http://httpd.apache.org

So to fix this, you might want to try something like the following pattern:

$pattern = "/^http(s?):\/\/.+$/";

Last but not least, you might want to make sure that the URL you are redirecting to hasn't been URL encoded somehow otherwise it will cause additional problems. This is probably a little unnecessary considering it shouldn't be encoded, but I like to be paranoid. To get around this, just decode it:

header('Location: '.[url=http://www.php.net/urldecode]urldecode[/url]($visitpage));

Happy coding :)

[internetheaven]

Which will still be deemed "correct" by your regex, as well. Obviously this is something that you'd want to avoid, so to do that you should just be using the $_GET['go'] super global as it will only be grabbing the 'http://www.example.com' part without having to removed the unnecessary data.

Thanks, but problem is that the majority of the URLs redirected to have many variables.

I agree with the other two issues raised, thanks.

Happy coding :)

I'm still very new to this so the majority is less-than-smile-creating! ;)

[eelixduppy]

>> Thanks, but problem is that the majority of the URLs redirected to have many variables.

I don't understand how that restricts you from using GET instead of grabbing the whole URI, because as stated above, it can cause issues. If you wanted to have variables in the URL redirected to, they would need to be URL encoded. For example:

/js/visit.php?go=http%3A%2F%2Fwww.example.com%2F%3Fvar%3Dsomething&var2=something+else

echoing $_GET['go'] with this yields: http://www.example.com/?var=something while 'var2' stays part of the original URL and isn't part of the redirected URL.