PHP Redirection with Post Parameters

I have a webpage. This webpage redirects the user to another webpage, more or less the following way:

<form method="post" action="anotherpage.php" id="myform">

    <?php foreach($_GET as $key => $value){
    echo "<input type='hidden' name='{$key}' value='{$value}' />";
    } ?>

</form>
<script>

    document.getElementById('myform').submit();

</script>

Well, you see, what I do is transferring the GET params into POST params. Do not tell me it is bad, I know that myself, and it is not exactly what I really do, what is important is that I collect data from an array and try submitting it to another page via POST. But if the user has JavaScript turned off, it won't work. What I need to know: Is there a way to transfer POST parameters by means of PHP so the redirection can be done the PHP way (header('Location: anotherpage.php');), too?

It is very important for me to pass the params via POST. I cannot use the $_SESSION variable because the webpage is on another domain, thus, the $_SESSION variables differ.

Anyway, I simply need a way to transfer POST variables with PHP ^^

Thanks in advance!


Solution 1:

You CAN header redirect a POST request, and include the POST information. However, you need to explicitly return HTTP status code 307. Browsers treat 302 as a redirect with for GET, ignoring the original method. This is noted explicitly in the HTTP documentation:

  • https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8

Practically, this means in PHP you need to set the status code before the redirect location:

    header('HTTP/1.1 307 Temporary Redirect');
    header('Location: anotherpage.php');

However, note that according to the HTTP specification, the user agent MUST ask user if they are ok resubmitting the POST information to the new URL. In practical terms, Chrome doesn't ask, and neither does Safari, but Firefox will present the user with a popup box confirming the redirection. Depending on your operating constraints, maybe this is ok, although in a general usage case it certainly has the potential to cause confusion for end users.

Solution 2:

No possibility to do this directly from server, as POST data should be sent by the browser.

But you can choose an alternative:

  • The prefilled form automatically submitted in your example could work, but as you wrote it's not really good practice and can leave users on a blank page
  • Receive GET arguments and POST them with curl (or any decent HTTP client) to the second site, then transfer the result to the browser. This is called a proxy and may be a good solution IMHO.
  • Do session sharing across domain, this can not be possible on all setups and can be complex. Once setup is done, session sharing is almost transparent to PHP code. If you have more than one need for communication between the 2 domains it can be worth doing this.

Example with curl solution, code to run on domain 1:

//retrieve GET parameters as a string like arg1=0&arg1=56&argn=zz
$data = $_SERVER['QUERY_STRING']; 

// Create a curl handle to domain 2
$ch = curl_init('http://www.domain2.com/target_script.php'); 

//configure a POST request with some options
curl_setopt($ch, CURLOPT_POST, true);
//put data to send
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);    
//this option avoid retrieving HTTP response headers in answer
curl_setopt($ch, CURLOPT_HEADER, 0);
//we want to get result as a string
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
//if servers support is and you want result faster, allow compressed response
curl_setopt($ch, CURLOPT_ENCODING, 'gzip,deflate'); 

//execute request
$result = curl_exec($ch);

//show response form domain 2 to client if needed
echo $result;

That's it, your client's browser won't even see domain 2 server, it will get only result from it. know if you want to redirect client to domain, do it with classic HTTP header.

header('Location: http://www.domain2.com');

Of course, this is demo code with hardcoded values, and there are 2 point left to you:

  • Security: query string should be filtered or recreated to transmit only needed parameters, and you should assert the server on domain 2 returned a 200 HTTP code.
  • Application logic should need a little adjustment on this part: if domain 2 app expects to get post data in the same request as visitor is coming it won't do it. From domain 2 point of view, the client doing POST request will be server hosting domain 1 not the client browser, it's important if client IP matters or other client checks are done on domain 2. If the POST request serves to display client specific content you also had to do some server-side tracking to combine previously posted data with the visitor being redirected.