JB’s Collection Difference between GET & POST Method Page No.

1 of 10

Source : http://www.cs.tut.fi/~jkorpela/forms/methods.html

Methods GET and POST in HTML forms - what's the

difference?
In HTML, one can specify two different submission methods for a form. The method is
specified inside a FORM element, using the METHOD attribute. The difference between
METHOD="GET" (the default) and METHOD="POST" is primarily defined in terms of form data
encoding. The official recommendations say that "GET" should be used if and only if the form
processing is idempotent, which typically means a pure query form. Generally it is advisable to
do so. There are, however, problems related to long URLs and non-ASCII character repertoires
which can make it necessary to use "POST" even for idempotent processing.

Content:

• The fundamental differences between "GET" and "POST"

• Why the distinction matters
• Differences in form submission
• Differences in server-side processing
• Possible reasons to use "POST" for idempotent queries

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
JB’s Collection Difference between GET & POST Method Page No.2 of 10

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.

Why the distinction matters

In the same context where the pragmatic difference is stated, the HTML 2.0 specification
describes the corresponding submission methods technically. However, it does not explain why
those methods are recommended for idempotent vs. non-idempotent submissions. Neither does it
explain what practical difference there might be between the methods.

Alan Flavell has explained, in an article in a thread titled Limit on URL length in the newsgroup
comp.infosystems.www.authoring.html, that "the distinction [between GET and POST] is a
real one, and has been observed by some browser makers, which can result in undesirable
consequences if the inappropriate one is used". He gives the following reason for conforming to
the advice:

When users revisit a page that resulted from a form submission, they might be presented with
the page from their history stack (which they had probably intended), or they might be told that
the page has now expired. Typical user response to the latter is to hit Reload.

This is harmless if the request is idempotent, which the form author signals to the browser by
specifying the GET method.

Browsers typically will (indeed "should") caution their users if they are about to resubmit a POST
request, in the belief that this is going to cause a further "permanent change in the state of the
universe", e.g. ordering another Mercedes-Benz against their credit card or whatever. If users get
so accustomed to this happening when they try to reload a harmless idempotent request, then
JB’s Collection Difference between GET & POST Method Page No.3 of 10

sooner or later it's going to bite them when they casually [OK] the request and do, indeed, order
a second pizza, or invalidate their previous competition entry by apparently trying to enter twice,
or whatever.

Thus, some browsers can act more cleverly if the author uses "GET" or "POST" consistently, i.e.
using "GET" for pure queries and "POST" for other form submissions. It needs to be noted,
though, that using "GET" gives no protection against causing changes. A script which processes
a form submission sent with the "GET" could cause a pizza ordering. It's just that authors are
expected to take care that such things don't happen.

Moreover, the use of "POST" cannot guarantee that the user does not inadvertantly submit the
same form data twice; the browser might not give a warning, or the user might fail to understand
the warning. Users are known to become impatient when it seems that "nothing happens" when
they click on a button, so they might click on it again and again. Thus, robust processing of
forms should take precautions against unintended duplicate actions. (As a simple example, a
submission might be processed first by a script which sends back a page containing a
confirmation request, echoing back the data submitted and asking the user to verify it and then
submit the confirmation.)

A "GET" request is often cacheable, whereas a "POST" request can hardly be. For query systems
this may have a considerable efficiency impact, especially if the query strings are simple, since
caches might serve the most frequent queries. For information about caches, see Caching
Tutorial for Web Authors and Webmasters, especially section Writing Cache-Aware Scripts.

Differences in form submission

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).
JB’s Collection Difference between GET & POST Method Page No.4 of 10

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.

Differences in server-side processing

In principle, processing of a submitted form data depends on whether it is sent with
METHOD="GET" or METHOD="POST". Since the data is encoded in different ways, different
decoding mechanisms are needed. Thus, generally speaking, changing the METHOD may
necessitate a change in the script which processes the submission. For example, when using the
CGI interface, the script receives the data in an environment variable when METHOD="GET" is
used but in the standard input stream (stdin) when METHOD="POST" is used.

It is, however, possible to construct libraries of subroutines (e.g. Perl functions) which allow one
to write scripts in a manner which works both for METHOD="GET" and METHOD="POST". This
would be based on distinguishing between the cases within the subroutine code and returning the
data to the caller in a uniform manner.

Possible reasons to use "POST" for idempotent queries

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).
JB’s Collection Difference between GET & POST Method Page No.5 of 10

• 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!

Source :http://www.faqs.org/faqs/www/cgi-faq/section-37.html

2.9 What is the difference between GET and POST?

Firstly, the the HTTP protocol specifies differing usages for the two methods. GET requests
should always be idempotent on the server. This means that whereas one GET request might
(rarely) change some state on the Server, two or more identical requests will have no further
effect.

This is a theoretical point which is also good advice in practice. If a user hits "reload" on his/her
browser, an identical request will be sent to the server, potentially resulting in two identical
database or guestbook entries, counter increments, etc. Browsers may reload a
GET URL automatically, particularly if caching is disabled (as is usually the case with CGI
output), but will typically prompt the user before re-submitting a POST request. This means
you're far less likely to get inadvertently-repeated entries from POST.

GET is (in theory) the preferred method for idempotent operations, such as querying a database,
though it matters little if you're using a form.

There is a further practical constraint that many systems have built-in limits to the length of a
GET request they can handle: when the total size of a request (URL+params) approaches or
exceeds 1Kb, you are well-advised to use POST in any case.

In terms of mechanics, they differ in how parameters are passed to the CGI script. In the case
of a POST request, form data is passed on STDIN, so the script should read from there (the
number of bytes to be read is given by the Content-length header). In the case of GET, the data
is passed in the environment variable QUERY_STRING. The content-type (application/x-
www-form-urlencoded) is identical for GET and POST requests.

Send corrections/additions to the FAQ Maintainer:

Nick Kew <nick@webthing.com>

Source : Microsoft
JB’s Collection Difference between GET & POST Method Page No.6 of 10

Developing Web Applications

The Difference between GET and POST

When the user enters information in a form and clicks Submit , there are two ways the
information can be sent from the browser to the server: in the URL, or within the body of the
HTTP request.

The GET method, which was used in the example earlier, appends name/value pairs to the URL.
Unfortunately, the length of a URL is limited, so this method only works if there are only a few
parameters. The URL could be truncated if the form uses a large number of parameters, or if the
parameters contain large amounts of data. Also, parameters passed on the URL are visible in the
address field of the browsernot the best place for a password to be displayed.

The alternative to the GET method is the POST method. This method packages the name/value
pairs inside the body of the HTTP request, which makes for a cleaner URL and imposes no size
limitations on the forms output. It is also more secure.

ASP makes it simple to retrieve name/value pairs. If the forms output is passed after the question
mark (?) on the URL, as occurs when using the GET request method, the parameters can be
retrieved using the Request.QueryString collection. Likewise, if the form is sent using the
POST method, the forms output is parsed into the Request.Form collection. These collections
let you address the form and URL parameters by name. For example, the value of the form
variable User can be passed into a VBScript variable with one line of script:

<% UserName = Request.Form("User") %>

You dont need to specify the collection ( Form or QueryString ) in which you expect to find
the User parameter. The following is an equally valid method of searching for the User
parameter:

<% UserName = Request("User") %>

In the absence of a specific collection, the Request object will search all of its collections for a
matching parameter. This is meant to be a programming convenience. However, the ASP
Request object also contains collections for ServerVariables and ClientCertificates , which
contain sensitive server and user authentication information. To avoid the possibility of spoofed
values, which are values entered by the user in the URL, it is highly recommended that you
explicitly use the collection name when searching for parameters from these collections.

The following script combines a form and an action (the script that processes the form) into a
single page. By posting the form data back to the same ASP page that displays the form, server-
side script can process the output of the form. This is perfectly valid, and for simple script is
often more convenient than posting to a second ASP page.

<%@ LANGUAGE="VBScript" %>

<!-- FILE: logon.asp -->
<HTML>
<HEAD>
<TITLE>Authentication Form</TITLE>
</HEAD>

<BODY BGCOLOR=#FFFFFF>
JB’s Collection Difference between GET & POST Method Page No.7 of 10

<% If Request.Form("User") = "" Then %>

<P>Please enter your Name:
<FORM ACTION="./logon.mspx" METHOD="POST">
Your name: <INPUT TYPE="TEXT" NAME="User">
Your password: <INPUT TYPE="PASSWORD" NAME="Pwd">
<INPUT TYPE="SUBMIT" VALUE="Log On">
</FORM>
<% Else 'User verification and logon code goes here %>
Welcome <%= Request.Form("User") %>!
<% End If %>

</BODY>
</HTML>

Note If you use a separate ASP file to handle the processing of a form, the Request.Form
collection will be emptied when you redirect to the new page. In order to retain the form values,
you must copy them to the Session object from which they can be accessed on subsequent
pages.

Although the sample authentication form shown here works, theres a good reason why you
would not want to use it in practice. Logon information is sensitive and should be subject to
rigorous protection from prying eyes. Although you can use the POST method to contain the
users password within the body of the HTTP response, it is still possible to intercept and read it.

For mission-critical applications, IIS 5.0 provides both secure authentication with integrated
Windows authentication and Client Certificates, as well as data encryption with Secure Sockets
Layer (SSL). For more information about authentication and encryption, see Security in this
book.

Source : http://www.jguru.com/faq/view.jsp?EID=56472

Q: What is the difference between POST and GET methods?

Question What is the difference between POST and GET methods? What about
PUT, DELETE, TRACE, OPTIONS, and HEAD? Derived from A question posed by
Amisha Patel Topics Java:API:Servlets Author Simon Brown Created May 25, 2000

Answer
GET and POST basically allow information to be sent back to the webserver from a browser
(or other HTTP client for that matter).

Imagine that you have a form on a HTML page and clicking the "submit" button sends the
data in the form back to the server, as "name=value" pairs.

Choosing GET as the "method" will append all of the data to the URL and it will show up in
the URL bar of your browser. The amount of information you can send back using a GET is
restricted as URLs can only be 1024 characters.

A POST on the other hand will (typically) send the information through a socket back to the
webserver and it won't show up in the URL bar. You can send much more information to the
server this way - and it's not restricted to textual data either. It is possible to send files and
even binary data such as serialized Java objects!
JB’s Collection Difference between GET & POST Method Page No.8 of 10

A PUT allows you to "put" (upload) a resource (file) on to a webserver so that it be found
under a specified URI. DELETE allows you to delete a resource (file). These are both
additions to HTTP/1.1 and are not usually used. HEAD returns just the HTTP headers for a
resource. TRACE and OPTIONS are also HTTP/1.1 additions and also rarely used.

The Servlet spec allows you to implement separate Java methods implementing each HTTP
method in your subclass of HttpServlet. Override the doGet() and/or doPost() method to
provide normal servlet functionality. Override doPut() or doDelete() if you want to
implement these methods. There's no need to override doOptions() or doTrace(). And the
superclass handles the HEAD method all on its own.

The full specs for HTTP are available (if you're interested) can be found on the w3c.org site.
See also the JavaDoc for HttpServlet.

[Edited/enhanced by Alex]

See also:

• How do I support both GET and POST protocol from the same Servlet?
• What is the difference between the doGet and doPost methods?
• How does one choose between overriding the doGet(), doPost(), and service()
methods?

Source : http://www.techmag.biz/dirrerence_between_get_post

What is the difference between GET and POST?

Submitted by Thejesh GN on April 13, 2006 - 2:52pm. Java | JavaScript

When you submit your HTML for to a server (say servlet), you can specify the method as GET
or POST.The form data reaches the server both the times. But in case HTTP GET the form
values are attached to url.They are taken as a part of URL.

HTTP GET: http://somehost/update?prevName=Raj&preName=Thej

[http headers]
[http body (empty)]

<form action="update" method="get">

HTTP POST: http://somehost/update

[http headers]
prevName=Raj&preName=Thej

<form action="update" method="post">

Now Java servet has seaparate methods to handle them, namely doGet and doPost. So that it
becomes easy for you to put your business logic.

GET v/s POST

JB’s Collection Difference between GET & POST Method Page No.9 of 10

1. POST is more safer then GET. Because the URL doesn't expose the data
2. The URL length has some limitation (Can't be more than 256 characters in some servers. But
generally has 4000 (4K) characters limit. And hence you can't send heavy data in GET.
3. GET request are re-executed when the user presses back button.
4. Search service will not index anything with ? in URI. ( some modern services may)
5. Resubmit - POST browser usually alerts the user ( no guarantee though).But GET doesn't
6. GET can't handle non-ASCII characters

When to use GET or POST

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.

How the form data is transmitted?

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.

Quote from CGI FAQ

Firstly, the the HTTP protocol specifies differing usages for the two
methods. GET requests should always be idempotent on the server.
This means that whereas one GET request might (rarely) change some state
on the Server, two or more identical requests will have no further effect.

This is a theoretical point which is also good advice in practice.

If a user hits "reload" on his/her browser, an identical request will be
sent to the server, potentially resulting in two identical database or
guestbook entries, counter increments, etc. Browsers may reload a
GET URL automatically, particularly if cacheing is disabled (as is usually
the case with CGI output), but will typically prompt the user before
re-submitting a POST request. This means you're far less likely to get
JB’s Collection Difference between GET & POST Method Page No.10 of 10

inadvertently-repeated entries from POST.

GET is (in theory) the preferred method for idempotent operations, such
as querying a database, though it matters little if you're using a form.
There is a further practical constraint that many systems have builtin
limits to the length of a GET request they can handle: when the total size
of a request (URL+params) approaches or exceeds 1Kb, you are well-advised
to use POST in any case.

I would prefer POST when I don't want the status to be change when user resubmits. And GET
when it does not matter.

Another Answer from a FAQ Forum:

A GET request is a request to get a resource from the server. Choosing GET as the
"method" will append all of the data to the URL and it will show up in the URL bar of
your browser. The amount of information you can send back using a GET is restricted as
URLs can only be 1024 characters. A POST request is a request to post (to send) form
data to a resource on the server. A POST on the other hand will (typically) send the
information through a socket back to the webserver and it won't show up in the URL bar.
You can send much more information to the server this way - and it's not restricted to
textual data either. It is possible to send files and even binary data such as serialized Java
objects!