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

I’m more or less accustomed to the browser incompatibility by now. Its one of the reasons I urge colleagues working as backend developers not to waste time in front-end. Too much to worry about. Time just flies when you are working on that IE5.5 specific bug which doesn’t occur anywhere else

Anyhoo, yet another issue came up when I was using the CSS a:hover property to change the background image (say img1.gif) of a button. I generally tend to go for CSS Sprites to reduce the number of image loads (each of them requires a different HTTP request all the way to the server). This makes it quite a big of an advantage for a site dominated by images.

Well, so one expects the image to change in millisecs, if not microsecs, on mouse hover, simply because its already present on the client machine. But NO. IE6 will request the server again for the image, irrespective of whether the file called was a different one (img2.gif) or the same one (img1.gif). This kind-of renders useless the benefits of CSS Sprites. In fact, it creates a situation far worse, because each time IE wants the specific image, it downloads the bulk of tiny images present in a single gif file.

A pretty quick client side hack is use of the javascript in the HEAD tag :

try {
document.execCommand("BackgroundImageCache", false, true);
} catch(err) {}

This makes sense since its a client side issue, but fixes the issue only in IE6 SP1 or higher. If folks want to have a server-side fix for this problem, the easiest one I found is modifying the server properties to cache images. This seems to be a clean fix, and also one that avoids multiple image downloads for the same image repeated across pages (Banners, menu, background). An example for Apache (modifying the .htaccess file) is pasted below

ExpiresActive On
ExpiresDefault A18000
ExpiresByType image/gif A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000

You can read more about this here and here.

After modification of .htaccess, I did notice quite a bit of performance improvement in page load time, even though the page was considerably light. No benchmarks or figures available, though

I see beginners in Java remembering the statements “Objects are passed by reference, primitive datatypes are passed by value”. Well that’s all fine, but it doesn’t really need memorizing once you know the basics of memory allocation (without the type information)

I give a pictorial view (simplified) of execution of some sample code

The standard memory representation is that of heap storage followed by the program stack

int a;

a = 10;

String b;

b = new String();

The basic method of parameter passing between methods is to “Pass values in stack”, which is equivalent of “Pass variables in stack by value”

Thus a call to foo (a,b) will pass value of a (10) as first parameter, and value of b (reference to heap location) as second parameter. Effectively, the String object gets passed as reference, while primitive datatype a gets passed by value.

This is analogous to passing pointers in C once the pointer is referencing a location created by malloc(). It is just this part that Java (and most other OO languages) implicitly provide for, by use of the keyword ‘new’ (or call to the object constructor)