Page 1 of 1

$_POST versus $_GET

Posted: Mon Sep 26, 2005 9:01 am
by sebs
Is there a difference between $_POST and $_GET?
In general and if I use them on pagination.

Posted: Mon Sep 26, 2005 9:21 am
by CoderGoblin
I am sure that this has been discussed before.

$_GET -> limited in length, obvious to users as they see it as part of the URL
$_POST -> Any length. May cause popups on refresh. Parameters hidden from casual user.

To access either in PHP use $_REQUEST.

Never assume they are valid as both may be "fooled" by users i.e never use them in an SQL command unless you have validated them beforehand as they may be able to do nasty things like delete your db (lookup SQL injection on the web).

Posted: Mon Sep 26, 2005 9:22 am
by shiznatix
$_POST is through headers...i think. $_GET is through the url. $_GET is visible by the user by just looking at the address bar where as $_POST is not. both of them have their advantages. $_POST almost always is sent by a user clicking a submit button where as $_GET can be sent by a person just clicking on a link.

edit: i was a bit late

Posted: Mon Sep 26, 2005 2:51 pm
by pilau
CoderGoblin wrote:To access either in PHP use $_REQUEST..
Don't use $_REQUEST. Security Holes.

Posted: Mon Sep 26, 2005 2:55 pm
by Nathaniel
pilau wrote:
CoderGoblin wrote:To access either in PHP use $_REQUEST..
Don't use $_REQUEST. Security Holes.
How is that? Anybody can put anything they want in any $_REQUEST var - $_COOKIE, $_POST, or $_GET. Just because it's not $_GET doesn't make it more secure...

$_REQUEST may make it a bit simpler for script kiddies, though.

Posted: Mon Sep 26, 2005 2:57 pm
by feyd
if you want to use $_REQUEST, build your own version, because the order in which elements are set can be easily changed from server to server, making your script act odd if multiples of a variable are sent.

Posted: Tue Sep 27, 2005 12:40 am
by Weirdan
and be aware that:
RFC 2616 wrote: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.