Code Away

Everyone who builds even the tiniest webapps has used a form submit. This involves (even if one uses flash, or any other front-end) use of http GET or http POST method to get the information from browser back to the server, where one can writhe and wrestle with it all one wants.

The big question often happens to be which method to use. The basic wisdom you get from the guy in the next cubicle (or from Microsoft) is

The GET method[...] 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 browser. Not the best place for a password to be displayed.

As always, there are some more things one ought to know as a responsible developer to get this distinction correct. Firstly the definition as per the HTML specification (which is extremely useful)

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.

The keyword “idempotent” says a lot. If the state of your application does not change with the number of times a request is sent with a parameter (set salary of X as 10,000 bucks) then the operation is idempotent.

A safer deal is to have form method as GET when the application state does not change at all (search for text in a file or database).

We will look at other practical differences between the two methods which further influence our choice (some of them are already covered by Microsoft. Yay!)

I attempt a tabular distinction below. Lets hope it is clear enough.

Http GET	Http POST
Encodes form parameters into URL(example: http://mysite.com/mypg?key1=val1&key2=val2)	Sends form fields to server without encoding them in URL
Has limited width FF2 : 8182 bytes Safari 2 : 8184 bytes IE7 : 2057 bytes	No upper limit for transfer
Can enable encoding of form only as application/x-www-form-urlencoded. No binary data / files can be sent	Can encode form values as multipart/form-data or application/x-www-form-urlencoded. The former encoding enables users to transfer files to server.
Page targeted can be bookmarked, since bookmark just remembers the complete URL	A big NO for bookmark, since the page is influenced by some parameters sent specifically by POST method.**
Values in hidden and password fields will be shown in the address bar of browser, as a result of everything being appended in URL	That’s not gonna happen here
Sending non-ASCII characters isn’t quite reliable	All character sets are safely sent where proper encoding is used

Some more detail on this with additional perspective is available here and here. Some perspective from grandmother’s viewpoint is available here

---

** Unless the page is rendered independent of transferred parameters, which for all practical apps is not the case