Menu
In the design process of my framework, I come to a point where I think about merging POST and GET parameters into one single $parameters variable.
The advantage for the developer: The framework filters all parameter values to secure agains XSS-attacks (i.e. funny kids inserting bad javascript code to redirect visitors to a spam site) and other sort of useful validation / filtering.
But as usual: Is there any real advantage to separating POST and GET, without respect to that they are just different because they come from different sources?
I mean: Does that matter? Would it be "good design" at any point, when a POST parameter has the same name as an GET parameter, and both are really used? In my eyes that's ugly, but maybe someone has a good explanation why I should not even attempt to merge POST and GET.
I would consider POST to be overriding GET in any case. I hope for honest answers :-)
979
POST request is comparatively more secure because the data is not exposed in the URL bar. Request made through GET method are stored in Browser history. Request made through POST method is not stored in Browser history. GET method request can be saved as bookmark in browser.
If you know the URL parameters for your form post when the HTML page is sent to the client, you can tack those URL parameters on to the form's action attribute, otherwise JavaScript can set the URL parameters when the form is submitted.
GET is less secure than POST because sent data is part of the URL. POST is a little safer than GET because the parameters are stored neither in the browser history nor in the web server logs.
GET requests should be used to retrieve data when designing REST APIs; POST requests should be used to create data when designing REST APIs.
POST and GETrequest have a different semantic. A short description is available on Wikipedia. Basically a GET request
should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause.
Note that this is not enforced by the HTTP protocol, it is something your application must ensure. Therefore you should separate the different HTTP verbs in your framework.
An example what might happen if a GET request is not simply returning a resource with the above-mentioned restrictions: Well-Intentioned Destruction.
52
I think everyone's missing the point of your question (or maybe I'm just misunderstanding it.) You're not asking the difference between GET/POST, you're wondering if its a good or bad idea for the framework that you're building to automatically merge the results of these two together into one safe variable. Both .Net and PHP do this so I don't see why not.
In PHP you can use $_GET or $_POST for a specific method or just $_REQUEST. Same with .Net, Request.QueryString and Request.Form vs Request. If someone has a reason to only get the POST/GET the variables are still there.
26
In some instances, accepting a GET rather than a post could make you more subject to a CSRF attack. That's not a hard and fast rule, however, and you should take steps to prevent CSRF even when accepting POST.
28
GET queries can be bookmarked, linked to, and are saved in browser's history. This can be good or bad; for instance, your users wouldn't want other people seeing that they visted example.com/?password=jigglypuff, or have someone tricked into clicking the link example.com/?changepasswordto=irh4x0r
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
