POST Method
FF
I would like send variable to php script from URL
using POST method. Is possible do it ?
( <a href="xxx.php">)
thanks for your help
FF
(¯`·..Yttrium ...·´¯)
d4sl1d$957$1...@nemesis.news.tpi.pl...
Hi,
Unfortunately, I dont think it's possible.
Bye
Erwin Moller
> Hello
>
> I would like send variable to php script from URL
> using POST method. Is possible do it ?
> ( <a href="xxx.php">)
>
Hi,
I am not sure what you mean, but is this helping?
make URL (with Javascript or whatever)
xxx.php?name=FF&number=42
from xxx.php:
$passedName = $_GET["name"];
$passedNumber = $_GET["number"];
Is that what you want?
Regards,
Erwin Moller
Erwin Moller
> FF wrote:
>
>> Hello
>>
>> I would like send variable to php script from URL
>> using POST method. Is possible do it ?
>> ( <a href="xxx.php">)
>>
>
> Hi,
>
> I am not sure what you mean, but is this helping?
>
> make URL (with Javascript or whatever)
> xxx.php?name=FF&number=42
>
>
> from xxx.php:
>
> $passedName = $_GET["name"];
> $passedNumber = $_GET["number"];
>
Or alternatively, with POST:
<form action="xxx.php" Method=:post">
<input type="text" name="name">
<input type="text" name="number">
<input type="submit">
</form>
and in xxx.php you retrieve them:
$passedName = $_POST["name"];
$passedNumber = $_POST["number"];
Regards,
Erwin Moller
Alvaro G Vicario
> I would like send variable to php script from URL
> using POST method. Is possible do it ?
> ( <a href="xxx.php">)
You need an intermediate script so you can:
1) Read the value from $_GET array.
2) Perform an HTTP connecion using the POST method.
Check the curl chapter, it may be helpful.
--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--
cowof...@gmail.com
<form action="page.php" method="post" name="myForm">
<input type="hidden" name="name" value="Mr NoName" />
<input type="hidden" name="number" value="52" />
<a href="#" onClick="myForm.submit(); return false;">Click Here</a>
</form>
All the form elements are hidden so it looks like your just clicking a
link, but be careful not to put any sensitive or private information
into the hidden fields as people can still see them when viewing the
page's source
Hope it helps
Michael Winter
> This has worked in the past for me:
Perhaps for a loose definition of "work".
[snip]
> <a href="#" onClick="myForm.submit(); return false;">Click Here</a>
If you must refer to a form, do it properly:
document.forms.myForm.submit();
However, the more important concern is of no client-side scripting
support. Navigation should never depend upon a script.
[snip]
The OP should consider if a POST request is really appropriate for the
task at hand. In other words, what's wrong with GET?
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
J Wynia
> If you must refer to a form, do it properly:
>
> document.forms.myForm.submit();
>
> However, the more important concern is of no client-side scripting
> support. Navigation should never depend upon a script.
And, if you're going to make absolute statements, you should do *that*
properly. Pedanticism is a 2 way street.
Navigation should never depend on a script where scripting engine
availability and compatibility can't be assured or the exclusion of
clients to whom the scripting functionality will be unavailable causes
undue harm.
Personally, I avoid absolute statements whenever I can, because I know
that my grasp of all possible scenarios is meager at best. And, absolute
statements, particularly those stating "rules" that aren't actually
scientific rules or laws tend to be based on a very specific set of
assumed criteria, which often don't match the questioner's situation.
This results in people following the "rules" to the detriment of their
project because they don't understand the reasoning behind the rules.
For instance, your rule against scripting is based on these assumptions:
1. Publicly accessible site with a "normal" distribution of browsers
including the most recent versions of Mozilla and IE as well as older
versions and more obscure browsers.
2. That a certain number of the viewers will have scripting either
completely incompatible or disabled.
3. That it is a "site" in the first place.
Not all of these things is true for every project. Seriously. I've built
PHP/Javascript applications that aren't accessed through a regular
browser at all. Rather, a customized wrapper around IE is used to launch
the app in fullscreen kiosk mode and is required to send the MAC address
of the ethernet adapter to be allowed into the app. In this case, there
was 100% IE and 100% Javascript compatibility/enabled. I could also
assume 1024x768 as all of the client setups were identical and imaged
from the same disk image. If I'd wasted time avoiding IE-specific
scripting or worked at all on cross-browser setup, I'd have been wasting
my client's money. The project would have suffered for blindly following
the rules.
So, what's the closest thing I use to a rule in regard to these kinds of
solutions? Figure out your userbase and make sure that *they* can use
it, whoever "they" are and quit clinging to absolute rules.
Remember, when someone asks how to do something, they may have a very
different purpose (an entirely reasonable purpose) in mind for the
technology. Just because you can't imagine a scenario that's
appropriate, don't assume one doesn't exist. Use the right tools for the
job.
Michael Winter
> Michael Winter wrote:
>
>> [...] the more important concern is of no client-side scripting
>> support. Navigation should never depend upon a script.
>
> [...] Pedanticism is a 2 way street.
To be pedantic, one must must be debating something irrelevant. I don't
think that challenging a course of action that may be unreliable would
fall under that category.
> Navigation should never depend on a script where scripting engine
> availability and compatibility can't be assured or the exclusion of
> clients to whom the scripting functionality will be unavailable causes
> undue harm.
I cannot argue that a statement along these lines would have been
better. However, I feel the important point is that an objection - well
phrased or not - has been raised.
Readers besides the OP may consider the answers in this thread and, even
if the solution is appropriate for the OP, it may not be for others. In
my experience, the misuse of client-side scripting occurs more often
than the avoidance of a scripted solution when it is appropriate.
[snip]
> 1. Publicly accessible site with a "normal" distribution of browsers
> including the most recent versions of Mozilla and IE as well as older
> versions and more obscure browsers.
> 2. That a certain number of the viewers will have scripting either
> completely incompatible or disabled.
> 3. That it is a "site" in the first place.
>
> Not all of these things is true for every project.
I am well aware of that, but I am used to the tendency of the Web being
the norm[1]. Perhaps that is not the case for this group. Are the
assumptions, without any other indication, so unreasonable? If not, and
the OP does have specific requirements or conditions, I would think it
sensible to mention them.
[snip]
Mike
[1] The specific circumstances may be irrelevant for many questions
to this group, but that is not usually the case once focus shifts
client-side.
Chung Leong <chernyshevsky@hotmail.com>
I have been meaning to write this one...
---------------------------------------
Q. How do I post a form to another site?
A. Use stream_context_create() to create a HTTP POST context, then open
a connection to the site in question with fopen(), passing the context
as the fourth parameter. Use fread() to read the result from the form
submission.
Example:
$post_vars = array(
'post_var1' => "hello",
'post_var2' => "world"
);
// build the request body
foreach($post_vars as $name => $val) {
$pairs[] = $name . '=' . rawurlencode($val);
}
$body = implode("&", $pairs);
// HTTP options
$opts = array(
'http'=>array(
'method'=>"POST",
'header'=>"Content-type: application/x-www-form-urlencoded\r\n" .
"Content-length: " . strlen($body) . "\r\n" .
"Cookie: foo=bar\r\n",
'content'=>$body
)
);
$context = stream_context_create($opts);
$f = fopen('http://localhost/test.php', 'r', false, $context);
In PHP 5, a context can also be passed to file_get_contents() and
file().
Although stream_context_create() is available since PHP 4.3.0, support
for HTTP POST has only become available in 4.3.5. If you are using an
older version, you would need the cURL functions or use fsockopen() to
open the connection and send the request with fputs().
[cURL example here]