[ Team LiB ] Previous Section Next Section

GET Versus POST

You might wonder why someone would choose to do a GET rather than a POST or vice-versa. Why is there even a choice? When you use the GET request to send form data, you're really taking advantage of a performance hack. By appending the form variables to the end of the pathname, you simplify the work that the server needs to do, because it takes a little more work to read posted data. For example, the corresponding GET request for the form data posted from the PostForm page looks like this:


GET /?foo=Foo%21&bar=Bar%3F&baz=%3C%3CBAZ%3E%3E HTTP/1.1

There is a limit to the length of the pathname for a GET request, however. So if the total length of your form variables is fairly long, more than 4KB, you can't use a GET request at all. Some servers won't even accept 2KB in a pathname. If you think the total length of your form data could be anywhere near the limit, you should use a POST rather than a GET.

In addition to the size limitations, there are other reasons to choose POST over GET or vice-versa. If you use the GET request to submit a form, and then bookmark the resulting page, the bookmark contains the form variables because they are part of the URL. You might consider this a good thing because it saves the user from having to type in the data. It might also be a bad thing, though, if one of the form items is a password. Not only is the password now saved as a bookmark, defeating the purpose of requiring a password, but also the password is visible in the browser's address window.

Protecting Your Form Data

graphics/didyouknow_icon.gif

If your form contains sensitive data, such as a password, use POST rather than GET. Although it does not protect the information as it goes across the wire, at least sensitive information does not appear in an address in a browser window, or even as a bookmark.


    [ Team LiB ] Previous Section Next Section