Is there any real reason to differentiate between POST and GET when handling incoming data?

Question

Lately I've been using a wrapper PHP class that fetches GET and POST data and lets me access it using a single getter function. After years of developing web applications I've never had a single good reason to care whether an incoming var was coming from POST or GET. Not only that but I got really sick and tired of having to check both arrays for a single variable.

Today I noticed that codeigniter has one getter function for POST data and one for GET. Is there any point to this? Has anyone here ever had a reason to care where his data is coming from?

A couple of clarifications: I'm not asking about the differences between POST or GET or which one I should use to send data to a page. I'm asking about whether I should care if data is arriving to my page via GET or POST.

Answer 1

You could care about the difference whether you want your data coming from a form (POST) or it being submitted through URL-parameters (GET). E.g. for security-reasons you wouldn't want to accept URL-data if you expect the user to fill out a form.

And just for the record: no need to check both arrays, in PHP the array $_REQUEST contains them both (plus COOKIE).

Answer 2

It is a question of semantics - if an interface (such as REST) requires a higher level of semantics, then that's one good reason to care about the HTTP "verb".

Answer 3

In cases of simple web forms, you probably don't care. But when security is at stake, you might well care about the difference: if somebody's putting a normally hidden input in a GET variable and you treat just as if it came from a POST, it's a potential attack vector.

In RESTful APIs, you definitely care about the difference: POST means a completely different thing than GET in this case, along with its much-neglected cousins, PUT and DELETE.

Answer 4

Well, the simplest answer is that knowing how your data should be received is important for security.

Often you can interchange between the types, but take logins for example, you woule be a fool to allow logins to be processed through a GET. I would love to look at your server logs and then be able to see the GET variables in the request log.. unlocking all users passwords.

There are lots of reasons in that POST requires slightly more resources also, so you don't want to force only POST requests. Take navigation through your site. How would someone bookmark a page if they navigate through sending POST commands.

You should normally just instintctively know which is best for you.

Answer 5

GET-Requests expose all the data to LOG-Files (yours and the proxies between), the Referrer and are visible to people looking at your browser.

Data via GET's are limited in length.

If you care about security: Why would you accept data sent by your forms via GET if you know your form method was POST?

Answer 6

That's a matter of your project politics. Either and Both have their respective places.

If you feel open and friendly, use $_REQUEST. If you feel fascist, allow only what you expect. If you feel hacky, use both and differentiate, say allow to preserve semi-persistent config by encoding it in GET and encouraging to bookmark the page, while filling POST with strictly volatile stuff.

One reason why you might really, really want to disallow GET is password fields and the like. You don't want your users to (unknowingly) store their sensitive data in browser history, so don't encourage them to do so by allowing GET. OTOH, you can "GET" from a plain <a href=""> so if you export any APIs for "anyone to use", provide either GET alone or both.

Answer 7

The HTTP standard defines different semantics for get/post operations (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html Sec 9.1.1)

In particular you can do information retrieval using data coming from a get request, but you shouldn't do anything which involves some notion of state change. One reason for this is that the user agent may prefetch pages (and doing get requests) without the user actually having clicked on a link. (Agreed that is notvery common among web browsers, but i've heard of mail clients doing that)