forms: post vs get

[Marty Chambers]

I'm not understanding this deal with forms.

method:"post"
method:"get"

What does that markup specify?

[ralph.m]

It just specifies what the form is meant to do. If it's a contact form, for example, the form will "post" information to the server. If it's a form for receiving some information (say from a database), it might need to "get" something. HTML can't do any of this, though. The actual processing has to be handled by a scripting language like PHP.

Do you "get" what I mean? If not, "post" again.

[Marty Chambers]

haha I understand clearly.

..except, I really don't understand why a form would ever need to "get" something. I thought forms were always used to SEND something to a server. When would one ever use the "get" feature?

Is it possible to have both "get" and "post" with one form?

[ralph.m]

When would one ever use the "get" feature?

As I said, you might need to get info from a database, for example. It's very common.

Is it possible to have both "get" and "post" with one form?

I'm pretty sure not, but it's not my area. (In a way, that's kind of what Ajax does--but that's a different situation.)

[Marty Chambers]

Well if one were to receive information from a database, why would it be necessary filling out a form if that database didn't receive the information? (i.e., forms would become pointless except perhaps filling out an email address for the database to send it to)

[ralph.m]

Yeah, actually, I think forms can handle post and get interchangably, but as I say, it's not my area. This is really a PHP question.

A quick Google search coughs up stuff like this: http://www.cs.tut.fi/~jkorpela/forms/methods.html

[Marty Chambers]

You haven't made it a point to study PHP? I'm a newbie at all this but it seems that all the heavy duty sites use PHP and JavaScript.

Thanks for the link, it looks really helpful

[felgall]

If you are using the form to retrieve information then you should use GET. That way the browser knows that you are only retrieving data and can cache the results so that if you ask for the same info again it doesn't have to go back to the server.

If you are updating something on the server then you should use POST as that tells the browser that the data is changing the server and so what comes back this time isn't going to necessarily be what comes back the next time the form is submitted.

The two are not supposed to be used interchangeably and many people use one when they ought to be using the other as they base their decision incorrectly on how the data gets passed to the server instead of what is being done with the data.

[ralph.m]

You haven't made it a point to study PHP?

I have studied the basics, but it is a big area, and I don't need it much. Most web designers can use a CMS to handle most operations, and although it helps to understand the PHP behind the scenes, you can get away without it (not that I'm really satisfied with that!) I'm gradually learning more, but it's not a main priority.

[AutisticCuckoo]

In an HTTP GET request, form field information is passed to the receiving application as query parameters in the URL.

In an HTTP POST request, the form field information is passed within the request body.

For instance, if the form has two parameters, name and age, and the action URL is /contact.php and the current domain is www.example.com.

With method="get":

GET /contact.php?name=Tommy&age=43 HTTP/1.1
Host: www.example.com
...

With method="post":

POST /contact.php HTTP/1.1
Host: www.example.com
...

name=Tommy&age=43

So using GET is not a very bright idea for a login form, because the password will be visible in plaintext in the URL.

On the other hand, GET can be very useful for a search form, because you can then link directly to the search results.

[felgall]

So using GET is not a very bright idea for a login form, because the password will be visible in plaintext in the URL.

It is also inappropriate because logging in results in a change on the server and you are supposed to use POST when updating the server and only use GET when you are requesting something that isn't changed as a result of your request. The selection should be made based on the purpose of the two commands (to write/post or read/get) rather than on how they pass their data.

[AutisticCuckoo]

It is also inappropriate because logging in results in a change on the server

It might, but it doesn't have to.

All the HTTP 1.1 specification (RFC 2616) really says is that GET requests should be idempotent (explained in section 9.1.2.)

Methods can also have the property of "idempotence" in that (aside
from error or expiration issues) the side-effects of N > 0 identical
requests is the same as for a single request.

Logging in, if it affects the server at all, could very well be idempotent.

[C. Ankerstjerne]

My rule of thumb is that if you need to be able to link to or share the target page to everyone, then you should use GET. If the target page is either secret, or it doesn't make sense to link to it, then you should use POST. Nothing's ever that simple, of course, but it'll get you a long way.

[Marty Chambers]

Woa this is way deeper than I thought. There's a lot more than just surface. I think I'm getting what you guys are saying, thanks