can anyone help me the exact difference between get and post types as far as i have learnt the post type cannot carry parameters with its url where as get can carry parameters in its url,is this correct?,
Fundamental Difference is probably the Visibility - GET request is sent via the URL string (appended to the URI with a question-mark as separator), which is visible whereas POST request is encapsulated in the body of the HTTP request and can't be seen.
Length - Since, GET request goes via URL, so it has a limitation for its length. It can't be more than 255 characters long (though this is browser dependent, but usually the max is 255 characters only). Whereas no such maximum length limitation holds for the POST request for the obvious reason that it becomes a part of the body of the HTTP request and there is no size limitation for the body of an HTTP request/response.
Performance - GET request is comparatively faster as it's relatively simpler to create a GET request and the time spent in the encapsulation of the POST request in the HTTP body is saved in this case. In addition, the maximum length restriction facilitates better optimization of GET implementation.
Type of Data - GET request is sent via URL string and as we all know that URL can be text-only, so GET can carry only text data whereas POST has no such restriction and it can carry both text as well as binary data.
Caching/Bookmarking - again for the obvious reason that a GET request is nothing but an URL hence it can be cached as well as Bookmarked. No such luxuries with a POST request.
FORM Default - GET is the default method of the HTML FORM element. To submit a FORM using POST method, we need to specify the method attribute and give it the value "POST".
Data Set - GET requests are restricted to use ASCII characters only whereas POST requests can use the 'enctype' attribute with a value "multipart/form-data" to use the Universal Multiple-Octet Coded Character Set (UCS).
Gangadhara Rao Duvvarapu wrote:Performance - GET request is comparatively faster as it's relatively simpler to create a GET request and the time spent in the encapsulation of the POST request in the HTTP body is saved in this case. In addition, the maximum length restriction facilitates better optimization of GET implementation.
I sincerely doubt that one could come up with a scenario where performance makes enough of a difference to trump other considerations (or even makes a measurable difference to begin with).
Ping & DNS - updated with new look and Ping home screen widget
There's also the matter of safety and idempotence to consider. Note that these apply to the HTTP/1.1 method definitions and need not necessarily be applied to the corresponding methods of HttpServlet, doGet() and doPost(), although that is strongly advisable.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
This is a common myth. A POST is no more secure than a GET. SImply because the parameters are not available on the URL does not make them in any way more secure than the parameters that are exposed.
The myth of security is not why on should choose a POST over a GET. HTTP defined how these methods should be used. In a nutshell, a GET is used to fetch an idempotent resources, whils a POST can cause a non-ideomtpotent changes to the server.
Bear Bibeault wrote:A POST is no more secure than a GET.
Well... that depends on what "secure" means in this context. POST parameters are recorded in fewer places than GET parameters - which can end up being stored in browser histories, web server access logs, HTTP caches etc. In that sense POST data is more secure. With respect to being observed in traffic, there is no difference.
The lack of recording affords so little added security that it's barely a blip. I think far too many people think that sending something like a password in clear text is "secure" because a POST is used. It is not.
Joined: Mar 22, 2005
Bear Bibeault wrote:The lack of recording affords so little added security that it's barely a blip.
That depends on what kinds of attacks are anticipated. Saying that something is "secure" is generally only meaningful with respect to particular attacks. Sometimes it's the common attacks one wants to guard against, sometimes the not so common ones.