Should my framework allow access to $_GET and $_POST at the same time?

Question

Hi,

I know you can use both $_GET and $_POST at the same time, but is this a required "feature"? I am writing a framework, where you can access input through:

$value = $this->input->get('name','');
$value = $this->input->post('name','');
$value = $this->input->cookies('name','');

I'm just thinking here, is there a need for having GET and POST at the same time? Couldn't I just do:

$value = $this->input('name','default value if not set');

To obtain GET/POST data according to which HTTP request was made? Cookies will be only accessible through ->cookies(), but should I use ->get() and ->post() instead of doing something like ->input() ?

Thanks for your input!

Answer 1

It's generally considered better to use $_GET and $_POST rather than $_REQUEST because it costs you nothing much and it closes off some small set of manipulations of the web site. I'd make the specific-source retrievals at least available in your framework.

Answer 2

Yes, but you might want to make sure that when using this code you check that the request method is POST if you are going to change anything as a consequence of the request, rather than treating GET and POST as the same thing.

This is because generally GET requests should not have any side effects, all they should do is 'get' stuff.

Edit This seems less relevant since you have clarified your question, but I will leave it here anyway

Answer 3

you could use just the input method but with flags incase the user wants input from a specific var:

$this->input('abc', '');
$this->input('abc', '', self::I_POST);
$this->input('abc', '', self::I_GET);
$this->input('abc', '', self::I_COOKIE);

Answer 4

It's conceivable that in a REST architecture I'd add a product like so:

POST /products?location=Ottawa HTTP/1.0

name=Book

And the product would automatically be associated with the location in the query params.

In a nutshell: there are semantically valid reasons for allowing both, but they can always be transformed into one or the other. That being said, do you want to enforce that usage on your users?

Answer 5

I would suggest keeping them separate, since they are used for separate purposes. GET is generally used for display purposes, while POST is used for admin purposes, adding/editing items, confirming choices, etc.

There may also be a slight security problem: someone could like to a page using GET parameters and force execution of something like deleting data - e.g. example.com/index.php?deleteid=123 (Actually this can be done with POST from an external HTML form but is much less common. Anyone can post a link on a forum, blog, anywhere.)

Answer 6

I would recommend keeping both POST and GET vars, since you can't predict how they are going to be used.

Most importantly be sure to validate against security exploits such as XSS, Sql injection in $_[POST|GET] before populating your objects.

Answer 7

I would say it highly depends on the situation. If you simply want to accept some parameters that will change how you display an HTML page (a typical GET variable) it's probably ok to accept both.

If you are going to work with forms, changing data and restricted access; you should look into the domain of CSRF and how this security issue might affect you.

In general, if you can be explicit about either, it's wise to do so.

Answer 8

Yes!
I think you must allow access to both $_GET and $_POST at the same time. And I don't think you can just merge them together either. (You can have the option to, like PHP and the ill concieved $_REQUEST.) You could get a request like:

POST /validator?type=strict HTTP/1.1

type=html/text
body=<h1>Hello World</h1>

Note that the variable name type is used twice, but in different scopes! (Once in the URI defining the resource that should handle the POST, and then in the posted entity itself.) In PHP this looks like:

$_GET => ('type' => 'strict')
$_POST => ('type' => 'html/text', 'body' => '<H1>Hellow World</h1>')

PHP:s way of just parsing the URI and putting the parameters there into $_GET is somewhat confusing. A URI is used with most (all?) of the HTTP methods, like POST, GET, PUT, DELETE etc. (Not just GET, like PHP would have you believe.) Maybe you could be revolutionary and use some of your own lingo:

$a = $this->uri('name');//param passed in the URI (same as PHP:s $_GET)
$b = $this->entity('body');//var passed in an entity (same as PHP:s $_POST)
$c = $this->method(); //The HTTP method in question ('GET', 'POST' etc.)

And maybe even some utility functions:

if($this->isGET()){
     ...
}elseif($this->isPOST()){
     ...
)

I know, wild and crazy :)
Good luck and have fun!
cheers!