Re: Using Header() to pass information...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jochem Maas wrote:

Todd Cary wrote:

If I use

  if ($send)
    header("location: mypage.php?message=" . $message);

the data ($message) is passed in the URL. Is there a way to pass the data as though it was a POST method i.e. not in the URL?


probably, but I don't know how off the top of my head.

look into using $_SESSION instead and maybe even consider that you
could save yourself a redirect by doing something _like_:

if ($send) {
    $_POST['message'] = $message;
    include './mypage.php';
    exit;
}

now sticking stuff into $_POST or $_GET probably isn't the best tactic -
if a security guru could comment on that I'd appreciate it also!


Todd


Actually, contrary (apparently) to what most people think on this list, it is *not* possible (well, not in a standards-compliant way). Basically what you do with a location header is stating that the URL provided is in a different location (using a 3xx status code). This in turn means (for most browsers) that they will make a new connection to the URI provided. You can redirect both POST and GET requests (and a hundred more), which should work fine in common browsers. A POST request getting a `303 See Other` status should be resent (with a nice "are you sure you wish to resubmit this data" prompt to the user; unfortunately, few browsers do this, though most common browsers (currently) do properly resend the data as part of a POST request to the URL provided.

Well, it's all very interesting up till now; the problem you're facing is that you do not with to *redirect*, you wish to *force the browser to initiate a specific type of request to a specific URI*, you use the 30x status codes to do this (which is actually incorrect usage, but let's just forget about / ignore that for now). That means the following:
1. a new URI is sent to the browser via the Location header
2. the browser makes a new connection to the specified URI with the original type (ie. POST, GET, PUT, etc. (not HEAD)) 3. the browser re-sends any additional data it was supposed to send (generally only in POST and PUT requests) Since there is no way for the server to "inject" data into that new request (except for the URI, which is why "get redirects" work), you can't "inject" a new POST request to a browser. Either you redirect the existing request (via a 30x status response), or you need to have the user re-submit a form (with potential new info provided by the script) to the new URI.

The RFC2616 HTTP/1.1 [1] document covers this in reasonable detail.
Also, google searches for "POST redirect request" will bring up a few articles detailing why this does not (and should not) work.

hope this help,
- tul

[1] http://www.w3.org/Protocols/rfc2616/rfc2616.html

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux