HTML and CSS Reference
In-Depth Information
GET where it's inappropriate can cause massive damage, up to and including the complete deletion of an entire
site. However, it's not hard to understand when GET is and is not appropriate.
Due to caching, GET URLs may measure fewer hits than a page accessed via POST. This might mean less
advertising revenue or budget. However, because GET URLs are so much more search-engine and user-friendly,
you'll more than make up for any reduced hits due to caches with increased hits due to actual visitors.
Furthermore, some simple modifications of cache-control headers can eliminate this issue entirely, without using
POST.
Mechanics
You should use GET for all operations that do not cause side effects. If following a URL simply results in the
server transferring some data to the client and nothing else, GET is appropriate. Anything that can be thought of
as simple browsing should be handled with GET, whether it's implemented with static files or with a server-side
script. The distinction should be irrelevant to the browser. Ideally, users shouldn't be able to tell whether they're
being served static files, live database queries, or cached database queries.
However, if a connection has major side effects, it should not be accessed with GET. For example, if the user is
charged a penny for each page loaded or each image viewed, those pages should only be loaded with POST.
Similarly, a user should read a contract with GET but only agree to it with POST.
Trivial side effects such as hit counters and log file entries don't need to be considered here. The real concern is
that users not be obligated in any way by following a link and GETting a URL. They don't buy anything. They
don't promise anything. They don't make anything happen. They're simply browsing through the store.
Query String Limits
There's a common myth that GET can be used only in cases where the data embedded in the query
string will be less than 256 characters long. This was true a long time ago, but hasn't been true for at
least ten years. All browsers from this millennium can easily handle URLs that are up to 2,000 characters
long, and more modern ones go well past that limit.
The big problem is Internet Explorer, which as of Version 7 still cannot handle URLs longer than 2,083
characters. This should be long enough for most forms that do not collect free-form input from the user.
Forms that do ask the user for unlimited amounts of text (comments on blogs, contact forms, etc.) can
usually legitimately use POST anyway.
I have encountered a few cases where
very
long query strings broke a server-side framework (PHP 4 in
particular). If this happens, you might temporarily use POST where GET is more appropriate. In the
longer run, though, you should upgrade to a server framework that does not impose such arbitrary
limits.
On the client side, changing a form to use GET instead of POST is easy. Simply change
method="post"
to
method="get"
on the
form
element. On the server side, details vary with framework, but the change is usually
easier than it should be. (Most frameworks really don't care whether any given form is submitted via GET or
POST, which has contributed to the myth that the difference doesn't matter. Indeed, some poorly written
frameworks accept all forms with both methods by default.)
If you're using Java servlets, renaming the
doPost()
method to
doGet()
is often all you need to do. In PHP, you
may have to do little more than replace
$_POST['name']
with
$_GET['name']
and carry on as though nothing
else had changed. Scripts that pay attention to the URL by which they were invoked—for instance, by echoing
Search WWH ::
Custom Search