Home : Topics : Forms and dynamic sites : Submitting forms
Form controls
Submitting forms
Processing submissions
< Previous: Form controls

Submitting forms

When a user clicks the Submit button, the form is submitted to the server as a standard HTTP request.

There are two form submission methods, which can be selected using an attribute of the <form> tag. One, called GET, causes the form data to be appended to the URL request. The other, POST, includes the form data elsewhere in the HTTP request and has a fixed URL.

Submission is standard HTTP request

When you submit a form, the browser sends an HTTP request to the Web server that includes your form data. This is a standard HTTP request; there is no fundamental difference between this request and a request for a normal URL.

The base URL for the Web server to which the form should be submitted is given in the <form> tag.

GET request

One way to submit forms is called a GET request. The GET request is the same type of request that's used normally to request a URL from the server. When submitting a form this way, the form data is converted appropriately and then included on the end of the URL.

For example, if the form URL was http://www.google.com/, and the form contained a single text field which had been given the name 'search', then after the user typed in 'apple pie' and clicked submit, the URL http://www.google.com/?search=apple+pie would be requested. (Spaces are converted to + because spaces are not permitted in URLs.)

POST request

The other submission method is POST. This works slightly differently; the browser contacts a fixed URL, which is not changed to handle different form data. However, the POST request includes the form data separately.

If the example form above used the POST method, then the plain URL http://www.google.com/ would be requested, but additional information would be sent to the server along with the request, including the 'apple pie' search term.

Choosing GET or POST

It can be difficult to decide which method is best for a particular form, but there are some specific rules.

The most important restriction is that forms sent using GET should not cause any significant action to be carried out. For example, a final order form at an online store should not use the GET method to place orders - but it would be acceptable to use a form with GET to retrieve customer information or to search the product database.

A general guideline is that if submitting the form data twice would be a problem - it might generate two orders, bomb two small developing nations, etc. - then the form must use POST instead of GET. This is required by the specification, and is important because Web browsers will never send POST data twice without querying the user, whereas they will send GET data again (thus ordering a second book or destroying a second country) if the user clicks their Back button.

Another advantage of POST is that it can cope with data of arbitrary length. GET, on the other hand, is restricted to relatively short data because URLs are limited in length. For example, GET could not be used for an email form (even if the above restriction did not apply, which it does) because the user might type a long email that won't fit in a URL.

GET, however, is useful when it is an option (for queries which don't cause any significant effect and which contain only a small amount of data) because GET queries are only standard URLs and can therefore be bookmarked, linked to, etc.