Skip to main content

The fundamental differences between "GET" and "POST"

The fundamental differences between "GET" and "POST"
The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.
The HTML 2.0 specification says, in section Form Submission (and the HTML 4.0 specification repeats this with minor stylistic changes):
If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be GET. Many database searches have no visible side-effects and make ideal applications of query forms.
- -
If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be POST.
In the HTTP specifications (specifically RFC 2616) the word idempotent is defined as follows:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
The word idempotent, as used in this context in the specifications, is (pseudo)mathematical jargon (see definition of "idempotent" in FOLDOC) and should not be taken too seriously or literally here. The phrase "no lasting observable effect on the state of the world" isn't of course very exact either, and isn't really the same thing. Idempotent processing, as defined above, does not exclude fundamental changes, only that processing the same data twice has the same effect as processing it once. But here, in fact, idempotent processing means that a form submission causes no changes anywhere except on the user's screen (or, more generally speaking, in the user agent's state). Thus, it is basically for retrieving data. If such a form is resubmitted, it might get different data (if the data had been changed meanwhile), but the submission would not cause any update of data or other events. The concept of changes should not be taken too pedantically; for instance, it can hardly be regarded as a change that a form submission is logged into the server's log file. On the other hand, sending E-mail should normally be regarded as "an effect on the state of the world".
The HTTP specifications aren't crystal clear on this, and section Safe Methods in the HTTP/1.1 specification describes the principles in yet another way. It opens a different perspective by says that users "cannot be held accountable" for side effects, which presumably means any effect than mere retrieval:
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.
The concept and its background is explained in section Allowing input in Tim Berners-Lee's Style Guide for online hypertext. It refers, for more information, to User agent watch points, which emphatically says that GET should be used if and only if there are no side effects. But this line of thought, however logical, is not always practical at present, as we shall see.
For both METHOD="GET" and METHOD="POST", the processing of a user's submit request (such as clicking on a submit button) in a browser begins with a construction of the form data set, which is then encoded in a manner which depends on the ENCTYPE attribute. That attribute has two possible values mentioned in the specifications, but multipart/form-data is for "POST" submissions only, whereas application/x-www-form-urlencoded (the default) can be used both for "POST" and for "GET".
Then the form data set is transmitted as follows (quotation from the HTML 4.0 specification):
  • If the method is "get" - -, the user agent takes the value of action, appends a ? to it, then appends the form data set, encoded using the application/x-www-form-urlencoded content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
  • If the method is "post" --, the user agent conducts an HTTP post transaction using the value of the action attribute and a message created according to the content type specified by the enctype attribute.
Thus, for METHOD="GET" the form data is encoded into a URL (or, speaking more generally, into a URI). This means that an equivalent to a form submission can be achieved by following a normal link referring to a suitable URL; see the document Choices in HTML forms for details and examples. On a typical browser, the user sees the URL of a document somewhere (e.g. on Location line), and if he is viewing the results of a query sent using METHOD="GET", he will see what the actual query was (i.e. the part of the URL that follows the ? sign). The user could then bookmark it or cut&paste it for later use (e.g. to be E-mailed or put into one's own HTML document after some editing).
Although the HTML specifications don't say it very explicitly, the fundamental difference between the methods is really that they correspond to different HTTP requests, as defined in the HTTP specifications. See especially Method Definitions in RFC 2616. For form submission with METHOD="GET", the browser constructs a URL as described above, then processes it as if following a link (or as if the user had typed the URL directly). The browser divides the URL into parts and recognizes a host, then sends to that host a GET request with the rest of the URL as argument. The server takes it from there. Submission of a form with METHOD="POST" causes a POST request to be sent.
For reasons explained above, one should normally use METHOD="POST" if and only if the form submission may cause changes. There are some exceptional situations where one may consider using METHOD="POST" even for pure queries, too:
  • If the form data would contain non-ASCII characters, then METHOD="GET" is inapplicable in principle, although it may work in practice (mainly for ISO Latin 1 characters). Thus, for a query where the keywords might contain e.g. accented letters, you have to select among two evils: using METHOD="GET" against the rules which restrict the character reportoire to ASCII within it, or using METHOD="POST" against the rules which says that it should not be used when the processing is idempotent. The latter alternative is probably less dangerous.
  • If the form data set is large - say, hundreds of characters - then METHOD="GET" may cause practical problems with implementations which cannot handle that long URLs. Such usage is mentioned in the the HTML 2.0 specification in an informative note as follows:
Note - The URL encoding may result in very long URIs, which cause some historical HTTP server implementations to exhibit defective behavior. As a result, some HTML forms are written using METHOD=POST even though the form submission has no side-effects.

The limitations are not only historical. There is an official statement by Microsoft, originally published 2000-02-23:INFO: Maximum URL Length Is 2,083 Characters in Internet Explorer
(Q208427).
  • You might wish to avoid METHOD="GET" in order to make it less visible to users how the form works, especially in order to make "hidden" fields (INPUT TYPE="HIDDEN") more hidden. Using POST implies that users won't see the form data in the URL shown by the user; but note that this is not a very effective method of hiding, since the user can of course view the source code of your FORM element!

Comments

Post a Comment

Popular posts from this blog

.NET Core: Session Wrapper Design Pattern For ASP.NET Core

Here, we'll learn about Session Wrapper design pattern to ease the access of Session. We'll make our access of session "Typed". Also, we may apply any validation or constraint in this wrapper class. Step 1 - Create a Session Manager class   In this example, we are going to store two items in Session (i.e. ID & LoginName). We are injecting IHttpContextAccessor so that we can access the Session variable.  We are creating properties which are actually accessing Session variable and returning the data or writing the data to Session. We have added one helping property "IsLoggedIn" which is using other properties to make a decision. We may have more such helping/wrapper properties. using Microsoft.AspNetCore.Http; public class SessionManager       {           private readonly ISession _session;           private const String ID_KEY = "_ID";           private const String LOGIN_KEY = "_LoginName";           publ
Post a Comment
Read more

Facade Design Pattern

Facade Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Motivation Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a  facade  object that provides a single, simplified interface to the more general facilities of a subsystem. Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler. Some specialized applications might need to access these classes directly. But most clients of a compiler generally don't care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level
Post a Comment
Read more

Tabla - An Indian classical instrument for Rythm

Tabla Indian music has fascinated the West for many years. The tabla in particular has attracted the attention of a number of American and European percussionists. It has been used in popular music as early as the 60's and is heard in the popular media even today. However, many percussionists shy away from this instrument. The reasons for not "getting into it" are varied. Sometimes it is the lack of instruments; sometimes lack of teachers; sometimes it is the belief that tabla is just too difficult. These are legitimate concerns but they are not insurmountable obstacles. This article will address the concerns of a musician just wishing to get started in tabla. We will discuss the theory of Indian music, how to purchase tabla, the basic technique, and compositional theory. All of this information should make the job of getting started much easier. We should first familiarize ourselves with the extensive theory of Indian music. Indian music is one of the oldest musical trad
Post a Comment
Read more

How to make a Method Thread Safe?

In multi-threaded applications where multiple threads make calls to the methods of a single object, it is necessary that those calls be synchronized. If code is not synchronized, then one thread might interrupt another thread and the object could be left in an invalid state. A class whose members are protected from such interruptions is called thread-safe. Although, there is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location , and this for each function (static or otherwise) that is accessing common objects. If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack: In this instance, multiple threads could call ThreadSafeMethod concurrently without issue. public class Thing { publ
Post a Comment
Read more

Create VHD using DISKPART

Create Virtual Harddisk Using DISKPART Open the   Elevated Command Prompt   with Administrator Privileges and type the following commands: DISKPART CREATE VDISK FILE="c:\win7\win7.vhd" MAXIMUM=20000 SELECT VDISK FILE="c:\win7\win7.vhd" ATTACH VDISK CREATE PARTITION PRIMARY ASSIGN LETTER=X FORMAT QUICK LABEL=Windows7 EXIT This will create the  VHD  file of primary partition. You will see the newly attached disk in Disk Management with Drive Letter X: Attaching and Detaching VHD in  Windows 7 Right Click  on My Computer and Click ' Manage ' that will open up  Computer Management , in that click on  Disk Management . Just like previous part. Then Right Click on Disk Management and select  'Attach VHD'.  This will open new windows  'Attach Virtual Hard Disk ' Click on  OK  and that will attach the existing Virtual Hard Disk. Now, if you don't want to make write anything on the VHD, we
Post a Comment
Read more