M. Sokolewicz wrote:
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
What I have done in the past is to open a new socket and pass the
data that way. Never had a problem, but I thought there might
be an easier way. Your detailed explanation tells why there is not.
Many thanks....
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
